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1.0 INTRODUCTION 

The Final Report (Volume 2), of the National Aeronautics & Space Administration study, 
"Definition of Avionics Concepts for a Heavy Lift Vehicle" was written by the Space Systems 
Avionics Group of General Dynamics. It was performed under contract NAS8-3578 for the 
Marshall Space Flight Center. 


1.1 Scope 

This document contains: 

• A summary of significant achievements and activities of the study effort. 

• Technical analysis and trade studies with necessary data to support the 
conclusions. 

• System and subsystem conceptual designs for reference vehicles and the Ground 
Based Testbed (GBT) with rationale for selection or rejection of the considered 
alternatives. 

The Final Report (Volume 2) also contains the majority of the material presented in the four 
quarterly reviews. Any study material not contained in this volume is in volume 3 (Program 
Cost Estimates) or was felt to be redundant or superceded by the material presented. 


1.2 Background 

The HLCV avionics study was originally meant to focus the development of advanced 
avionics systems for various space vehicles for the next ten to fifteen years. Figure 1 .2-1 
shows the role the HLCV Avionics study was envisioned to play. Scoped to start with an 
expendable, Shuttle derived booster, it was to define an optimum progression of upgrades 
and transitions until a fully reusable fixed wing booster system was achieved. Not limited to 
boosters, the study was to explore second stages, recoverable modules, and the attendant 
ground support systems. 

Methods for accelerating the application of beneficial new technologies to existing and future 
systems were needed. To this end, a Ground Based Testbed was to be defined. Though not 
a stated goal, lowering the overall cost per pound of orbiting a payload drove the study to 
include the definition of the optimal mix of ground and airborne check out capability. 
Autonomous operation of the far term vehicles was felt to be a logical goal. 

Shortly after the first review, the customer directed a shift in emphasis to a more detailed 
definition of the Ground Based Testbed, (GBT), that would support development of the HLCV 
avionic systems. The HLCV reference vehicle avionic systems were defined to the level 
required to size the GBT main processor, G&N Extension, and interconnecting busses and 
networks. 

A target implementation schedule was provided by MSFC in October linking the HLCV GBT 
and the Marshall Avionics System Test bed (MAST) efforts (see Figure 1 .2-2.). Also defined 
were specific functional support levels with dates and projected budget allocations A 
candidate site for the GBT/MAST was also provided The third Quarter Review reflected these 
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inputs and specifically costed the Phase 1 lab configuration. For purposes of this study the 
terms MAST and GBT are synonymous. 



FIGURE 1.2-1. HLCV AVIONICS STUDY: FOCUS FOR AVIONICS ADVANCED DEVELOPMENT 



FIGURE 1.2-2 HLCV / MAST IMPLEMENTATION 
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1.2.1 Study Objectives 

The initial objectives of the study were enumerated in the Study Plan as: 

1. Define the avionics requirements and recommended avionics concepts for an 
expendable Heavy Lift Cargo Vehicle in the 1992-1995 time span. 

2. Define the avionics requirements and recommended avionics concepts for a highly 
reusable HLCV to be operational in the 2000 era. 

3. Define the requirements, concepts, developmental plans, and costs for an avionics test 
bed(s). The avionics test bed will support the development and testing of the 
recommended vehicle and vehicle support components, software modules, 
subsystems and systems. 

4. Develop a transition plan from the expendable to the highly reusable HLCV. 

5. Develop a follow-on plan to define advanced development activities. 

As previously stated, the study emphasis shifted to definition of the avionics test bed, 

Objective #3, shortly after the first Quarterly review. Details were hammered out in the August 
Technical Interchange Meeting (TIM). The study plan was changed and a no-cost contractual 
change initiated to offset the additional tasks and products associated with this change, 
objectives 4 and 5 were re-scoped and de-emphasized. 

1.2.2 Study Tasks & Schedules 

Figure 1 .2.2-1 is the revised Master Schedule that reflects the final contract changes. The six 
major task classifications are shown and the deliverables identified. 

1.2. 2.1 Technology Assessment 

This task consisted primarily of completing the data base of relevant technologies that would 
be involved in the avionics system design of the three reference HLCV configurations. 

Section 2 lists nine of these technologies. They range from Computer Languages to large 
Electro Mechanical Actuators. The most promising candidates were chosen for Trade 
Studies. 

1.2. 2. 2 Trade Studies and Technical Analysis 

This activity continued far beyond the original estimates. With a change in emphasis to the 
definition of the GBT, trade studies or some level of technical analysis were performed 
beyond the 3rd Quarterly Review. Initially, trades were performed on the feasibility of using 
non-STS avionics equipment in the initial HLCV. Section 3 of the Final Report contains the 
RVU/EIU study which is typical of this type of trade. It was the "Tech Demo" to determine the 
best Main Processor for the GBT that extended beyond the planned time. This study 
considered over 20 candidates who were evaluated against criteria based in GBT processing 
and use requirements. The final selection will be based upon actual performance on 
contractor and customer supplied benchmark programs. 
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1.2. 2. 3 Requirements 

Initially centered on the three HLCV avionic system configurations, these requirements 
shifted to defining the GBT functional capabilities and interfaces. Section 4 covers these 
vehicle and GBT requirements. 
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FIGURE 1 .2.2*1 REVISED MASTER SCHEDULE 


1.2. 2. 4 Ground Based Testbed Design Definitions 

Formally called Concept Definition, these task represents the culmination of the three 
preceding tasks. The GBT design includes a three step implementation schedule which has 
specific support capabilities linked with developing programs. The design includes both 
hardware and software. The scope of definition includes Phase 1 , Phase 2 and the "full up", 
or Target configuration. Design details of the Phase 1 configuration are sufficient to cost the 
hardware and software. Phase 1 interface details is also provided in the Preliminary Design 
Document. Section 4 details all three GBT configurations. 

1.2. 2. 5 Programmatic Analysis 
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Three subtasks dominate this activity. The first in importance is GBT implementation 
planning. Several variables factored into this analysis are: 

• Customer Provided Goals & Missions 

• Development Schedules of Programs to be Supported 

• Availability of Hardware and Software 

• Facility Availability/Modification Schedule 

• Funding levels 

The Facility Requirements are driven by the Target GBT configurations and the 
implementation schedule. Funding for facility modifications may come from different sources 
than that of the GBT itself. This would represent still another driver of Facility Requirements. 

The GBT documentation, which includes the Cost Data, is a very important product. Though 
addressing the final or Target Configuration at a survey level, the GBT documentation covers 
the initial Phase 1 configuration thoroughly enough to cost the hardware and software. 

1.2. 2. 6 Deliverables 

The contractual Data Requirements (DR's) are shown on the bottom of Figure 1 .2.2-1. 


2.0 GROUND BASED TESTBED (GBT) DESIGN OBJECTIVES AND 
PHILOSOPHY 

The GBT is envisioned as a general resource facility providing to new vehicle programs a 
cost effective method of evaluating the concepts and technologies employed in their design. 
This resource will permit complete end-to-end simulations of system operation in the 
simulated mission environment desired. 

The GBT is to be set up to encourage use by all HLCV era vehicles during their initial design 
phases. Review of past projects involving total vehicle or subsystem development have 
repeatedly shown the need for such a readily accessible and powerful test and evaluation 
facility. The traditional dedicated test and development facilities have not been able to 
support their projects early enough to optimize system requirements and design. New 
projects must initially use facilities dedicated to other projects . Seldom do such facilities 
provide all the necessary testing capabilities or time for the required work. 

The key to the HLCV GBT success is seen to simply be: Cost Effectiveness . To obtain this 
objective, the Lab must be readily accessible at the time when new projects traditionally don't 
have their own dedicated facilities. GBT access must be simple and bound with a minimum of 
red tape. Once accessed, the GBT must provide a user friendly environment, an 
environment that can quickly be configured to access the required testing and logging 
resources. The resources must be capable of evaluating the concepts, technologies or 
designs to the required level of accuracy and against recognized performance benchmarks. 
Finally, the GBT must provide not only easy replication of the testing, but also provide the 
ability to thoroughly analyze the results and report the results in forms which effectively 
communicate their significance. 
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2.1 GBT Objectives 

The major objectives for the GBT are to provide a cost effective, multi-user simulation, test 
and demonstration facility to: 

1 Support early development and quantitative evaluation of proposed avionics 
systems during the early phases, (phase A/B),of a program. 

• Surfaces avionics, systems, integration and software problems early 

• Supports early requirements development 

2 Accelerate new avionics technology- testing and application to future programs. 

3 Provide a productivity center for evaluating/demonstrating major new design 
advances from NASA and industry. 

4 Promote continuity of avionics architectures, software, and hardware across 
projects. 

5 Demonstrate the "integration-ability" of new subsystems or components and their 
impact on the performance of an existing vehicle system. 

Figure 2.1-1 shows four HLCV era vehicles to be supported by the GBT. The first two are 
shuttle derived vehicles, SDV-2ES and SDV-2R. The 2R version has reusable propulsion 
and avionics as opposed to being expendable as the 2ES is. An alternative to the SDV-2RS 
is the Advanced Launch System Core and Booster. The fourth GBT supportable vehicle 
shown is the Fully Reusable Booster/Partially Reusable Cargo Vehicle, FRWB/PRCV. In 
addition to these, the GBT will also support upper stages, the Space Transfer vehicles, and 
several payloads. 
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FIGURE 2.1-1 HLCV ERA CANDIDATE VEHICLE CONFIGURATIONS 


2.2 GBT Philosophy 

The major points upon which the GBT design philosophy is based are: 
a. Reconfigurable Design 
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b. Real Time 

c. Functional Testing 

d. Modular Design 

e. Flexible 

f. Demonstration Oriented 

g. User Friendly 

The broad based, non project dedicated, generic nature of the GBT is implied in the first 
point. The GBT must be an evolving facility, capable of supporting several current and near 
term avionic systems. This translates to a firm requirement for rapid reconfigurability. It must- 
not only be able to switch from one test configuration to another, but it also must have 
sufficient capability to support several parallel efforts simultaneously. These efforts will 
include everything from basic pvaluation of single units in an open loop environment, to full 
up, multi-string system simulation. 

To be truly useful to a number of projects simultaneously, the GBT must accommodate a 
variety of software and hardware configurations. This characteristic encompasses several 
traits which include an continuing capability to support several current and near term avionic 
systems. Implicit to this capability would be a rapid and easy reconfigurability made possible 
by an architecture that presents a broad compatibility to both hardware and software. This 
compatibility includes the ability to provide a Real-Time hardware and software interface. 

This interface must be capable of duplicating the normal interface the Unit Under Test 
encounters in its native system. Only with such an interface can testing and evaluation be 
carried out at the required level of fidelity. Just as important is the ability to precisely 
manipulate the interface characteristics. Fault insertion and off limit operation can enhance 
the thoroughness of testing. 

The GBT is modular at all functional levels so, as it develops and the support requirements 
change, the lab can add or access the required resources. This translates to the GBT being 
able to accommodate any vehicle or system simulation of similar complexity to the then 
current defined reference vehicle and systems. Modular design in both the GBTs hardware 
and software facilitate an orderly expansion of capability. The foundation of hardware model 
benchmarks will be validated against real equipment. Once proven, a combination of real 
and simulated hardware models can be utilized to evaluate any number of proposed system 
architectures. 

Since one of the GBTs primary functions is to provide timely support to new projects, it must 
have the ability to quickly adapt to the specific needs of those projects. This flexibility must be 
a basic consideration in the GBT architecture so it can perform that level of testing or 
simulation required in a more cost effective manner than currently available to new projects. 

The current implementation plan for GBT establishes an August 1990 IOC to support Shuttle- 
C, (figure 1.2-2). In actuality, the GBT will have more than half of its total planned capability at 
this point. The software tools and models developed for the Shuttle-C are basically generic 
in nature, with separate data files supplying the unique values for this vehicle, its subsystems, 
and mission profiles. In most cases, only data set value changes would be required to switch 
from one vehicle configuration to another. 
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3.0 TRADE STUDIES AND TECHNICAL ANALYSIS 

Several technical issues had to be resolved prior to the definition of the three HLCV avionic 
system designs and the Ground Based Test Bed. 

The range of studies and analysis originally considered covered the three HLCV reference 
vehicles and the GBT. Those chosen for further study included: 

• Vehicle Processors 

• Software Language and Tool Selection 

• Inertial Measurement Unit 

• RVU replacement of EIU 

• Flight Control Actuators 

• Vehicle Power 

• Ground Systems 

• Lab Architecture 

• Data Buses and High Speed Networks 

• Instrumentation - Data Acquisition Systems 

• GBT Main Processor Selection 


3.1 Vehicle Processors 

The Vehicle Processor trade studies looked at currently available and developing 16 and 32 
bit CPUs for application in the full range of HLCV reference vehicles. Selection of the best 
current CPU for the HLCV centered about the 16 bit, 1750 processors. Figure 3.1-1 shows 
the units investigated. Figure 3.1 .1 -1 shows the 32 bit processors considered for far term 
application. 

3.1.1 Vehicle Processor Selections 

Due to the rapidly changing developments in this area, the majority of this study effort was 
spent on candidate processors for near term application. Criteria used in evaluation 
included: Availabity, Risk, Performance and broadness of application, (Use). The PSC 
1750A was selected for near term applications due to its current levels of performance, 
qualification and support. The 32 bit processor analysis shown reflects graphically the 
rapidly changing picture in that area. Completed in May of 1988, the most promising 
candidate the MC6830 would be hard pressed today, by the MC88000 and other newly 
introduced CPUs. 

Results: 

• Additional research required to select the optimum 32-bit processor 

- Space qualification, SEU hardness 

- Hardware cost and software support 

- Industry support 

• Note: 1740 will have lots of legacy and support well into the year 2000 

- B-2, V- 22, F-16C/D (Block 40G) 

- Centaur, Titan (proposed) 

• ATR/ATA 

- GD baselined today is 32 bit avionics 

- Flight control undecided (Currently 1750) 
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FIGURE 3.1. 1-1. TECHNOLOGY MATRIX: 32 BIT PROCESSOR 


Recommendations: 

* Select existing PSC 1 750A design 

- High SEU Tolerance/Latch-up immune 

- 1 .4 MIPS throughput at 25 MHz (2.5 MIPS at 40 MHz) 

- Bulk/SOS Conversion already performed on gate array 
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3.2 Computer Languages 

Nine criteria were examined in selection of the software language to be used in the GBT, 
Vehicle, and ground Checkout facilities. Figure 3.2-1 summarizes these results. Ada was 
chosen for use in vehicle software related functions with "C" selected for use in special test 
equipment and small simulations until software and tools become available in Ada. 
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FIGURE 3.2-1. TECHNOLOGY MATRIX - COMPUTER LANGUAGES 


3.3 Inertial Measurement Unit 

Candidates for near and far term HLCV inertial sensors were evaluated in this study. Though 
guidance and navigation technologies are not fully dependent on this type of sensor, it is felt 
that with the future shift to autonomous operations, inertial sensors will continue to play a 
significant role. Figure 3. 3. 2-1 reviews the spectrum of Guidance and Navigation 
Technologies. Figure 3.3.2-2 shows the inertial measurement units compared. Criteria used 
in this evaluation included: availability, accuracy, compatibility cost, and technical risk. 

Results: 

• Select Centaur IMS 

- Lowest Drift 

- Compatible with Standard 1 553 I/O 

- Low Weight 

- Uses state-of-the-art technology (ring laser) 
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FIGURE 3.3-1. GUIDANCE & NAVIGATION TECHNOLOGIES 
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FIGURE 3.3-2 TECHNOLOGY MATRIX: INERTIAL MEASUREMENT UNIT 


3.4 Engine Interface Unit (EIU) Replacement 

The feasibility of replacing the current Shuttle Engine Interface Unit (EIU) with a modified 
Remote Voter Unit (RVU II) was investigated for the SDV-2ES (Shuttle C). 

3.4.1 EIU Description 

Figure 3.4.1 -1 is a functional block diagram of the EIU that shows the processes that would 
have to be duplicated by the RVU II Figure 3.4. 1-2 shows the EIU interfaces and describes 
their functions and charactoristics. . Figure 3.4. 1-3 depicts the data flow between the Shuttle 
General purpose Computers, (GPCs), and the Main Engines. The EIU transmits commands 
from the Orbiter GPCs to Main Engine Controllers. When data and status are received by the 
EIU, the data is held in a buffer until an orbiter computer request for data is received by the 
EIU. 
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FIGURE 3.4.1-1 EIU FUNCTIONAL BLOCK DIAGRAM 


GPC's 

4 bidirectional 4- *| 
buses 
28 bit word 
format 
manchester 



3 serial 
“buses 


"2 serial 
N— buses 


CONTROLLER 
OUTPUT: 

• 33 bit word 

• 2 sync & 1 5 data & 1 5 BCH 

• manchester biphase 

• less than 1 ms skew between 
any 2 channels 

INPUT: 

• 19 bit word 

• 2 sync & 1 6 data & 1 parity bit 

• 128 word vehicle data table 

• manchester biphase 

• less than 24 ms skew between 
any two channels 

• 4 bidirectional serial data buses between GPCs and EIU command words/command 
data words and response words are 28 bits in length 

• 3 dedicated output serial data buses to the controller command words/ memory load 
data words are 33 bits in length 

• 2 dedicated input serial data buses from the controller status words/memory read data 
words are 19 bits in length 

• Synchronizing setup for all buses 

• Uses buses chaudhuri, hocquenghem (BCH) encoding. Used to detect and reject 
error patterns 

. Manchester coding used 

• Ability to load the controller memory in the buffered memory, load mode or the direct 
memory load mode (up to 10 word pairs) (full memory capability) 

• Ability to read the controller memory. Output is in the form of a 128 word data table 
. Status information is a 128 word data table 

• Memory load in the buffered mode supplies 16 bits of real data for each word pair 
(62 bits) 


FIGURE 3.4. 1-1 . EIU INTERFACE DEFINITIONS 
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FIGURE 3.4.1-3. EIU DATA FLOW 
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FIGURE 3.4.1 -4. EIU BUS INTERFACES 
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Figure 3.4.1 -4 shows the EIU bus interfaces, while figure 3.4.1 -5 summarizes the results. 
Though future plans point to simpler engine control requirements, the current assumptions, of 
a total functional replacement for the SSME EIU didn't prove to be economically feasible. 
Notable, however, is that this study lead to investigation of RVU replacement of the Orbiter 
MDMs and RJD in the SDV-2ES avionics system. This in turn lead to the Shuttle C Option C 
avionics configuration. The Concept Definition Section contains this design. 
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• THE ABOVE ARE RANKED IN ORDER FROM HIGHEST TO LOWEST 
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NOTE: Reduced Engine Control Requirements may alter conclusion. 

FIGURE 3.4-1. RVU ll-EIU TRADE STUDY RESULTS 


3.5 Flight Control Actuators 

The large Thrust Vector Control, (TVC) actuators proved to be the major area of concern in 
the developing area of Flight Control Actuators. Mid and Far Term vehicles will employ 
significantly more engines. The five primary ascent engines of the Shuttle will give way to 
clustered engine configurations using 14 to 20 engines on some future applications. The 
impact to ground processing and maintenance look to be intolerable if hydraulic actuators 
are retained. Electromechanical and Hydrostatic actuators present a better solution. Large 
EMAs, of the 50+ Horsepower range required, are still in development. Though control 
system design is adequate, development is needed in the power supply and distribution 
system areas. Figure 3.5-1 shows the three types of actuators investigated. 

Recommendations included the retention of hydraulic actuators on near-term vehicles that 
still had relatively few engines. Design provisions should be made, even on these vehicles, 
for replacement with EMAs in the future. Emphasis on EMA and ancillary system 
development was felt to be imperative in light of the potential savings in maintenance, 
production and ground operations costs. Performance gains were felt possible, particularly 
in reusable, clustered engine configurations. Here the potential weight savings and 
increases in system reliability are significant. 

3.5.1 Recommendations 

Select hydraulics until EMA technology matures. Reasons include: 

• Currently in place 

• Reliable and Flight Proven 

• Does not require additional power supplies. 

Select EMA in the near future. Reasons include: 

• Less maintenance 
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• Future decrease in production costs 

• Reduction in ground operations, and 

• Less weight. 
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FIGURE 3.5-1. TECHNOLOGY MATRIX: ACTUATORS 


3.6 Vehicle Power 

The HLCV short duration missions seemed to dictate from the start that batteries rather than 
fuel cells would be the logical choice. A number of batteries were examined, along with a 
generic fuel cell, for near and far term applications. Figure 3.6-1 shows the general results. 
The analysis pointed to Lithium Thionyl Chloride as the best primary battery with Zinc Silver 
as a good back-up source. Fuel cells were shown to become more viable on long duration 
missions. 

Power Distribution System designs were also explored. High and low voltage DC systems 
were compared with AC systems whose frequencies ranged from 400 Hz to 20 KHz. The 
standard 28 VDC system was shown adequate for near term designs. When EMAs are 
integrated into the HLCV era vehicles, a complete in depth reappraisal must be done. 

3.6.1 Power Distribution 

Three major types of distribution are: 

• 28 VDC Distribution 

• High voltage distribution (270 VDC) 

• AC Voltage distribution (400 Hz - 20 KHz) 
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Results: 

• Lithium thionyl chloride batteries are recommended for all three versions of HLCV 
for short duration missions 

• Zinc silver batteries will serve as a backup source in case problems develop with 
the prime batteries 

• Trade off fuel cells vs. batteries for missions of longer duration 
Recommendations: 

• 28 VDC distribution system is recommended for HLCV systems 

• Will trade-off distribution system for HLCV when EM actuators are used 
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FIGURE 3.6-1. TECHNOLOGY MATRIX: POWER GENERATION 


3.7 Ground Systems 

HLCV Ground Systems were viewed in terms of current practices and trends verses what far 
term trends best met program goals. The basic question of how much of the ground checkout 
and airborne checkout capability should be given to the vehicle avionics system had to be 
addressed. The use of Ground Systems for more than basic vehicle checkout and launch is 
gaining favor. 

Figure 3.7-1 summerizes some of the established Ground System requirements. Figure 3.7- 
2 identifies those ground processing functions where automation via Ground Systems would 
be benificial. 

3.7.1 Current Ground Systems 

To meet the IOC for the initial reference vehicle, a currently available Ground System must be 
adapted to meet the reference vehicles checkout and launch processing requirements. The 
two systems considered were the Titan Centaur Computer Controled Launch System, 
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(CCLS). and theSpace Transportation System Launch Processing System, (LPS). The 
following is a brief summary of CCLS and LPS applicability. 

CCLS 

• To use CCLS at both launch pads would require modifying both areas at an 
unknown cost. 

• CCLS can monitor around 1,100 downlink telemetry measurements 

• The third or final version (reusable) of HLCV would probably overtax the capability 
of CCLS 

• CCLS is cheaper to operate and maintain than LPS 
LPS 

• LPS is already in place at launch pads 39A and 39B 

• LPS has a greater telemetry downlink capability than CCLS 

• The reusable version of HLCV would benefit from the greater monitoring and 
control capability of the system 

• LPS has higher operating cost than CCLS 
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FIGURE 3.7. 1-1. CCLS 


Figures 3.8.1 -1 and 3.8.1 -2 show the CCLS and LPS functional block diagrams. Figure 
3.8.1 -3 compairs the two current systems and an advanced Network based, distributed 


Pago 18 


9/25/89, 11:40 AM 




























Final Report, Volume_2 Definition ofAvionics Concepts fora HeayyJJfjCar^_Vehj^ 

system using five criteria. The LPS was chosen for Phase 1 use primarly on a compatability 
basis. 
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FIGURE 3.7. 1-2. PRELIMINARY CONCEPT ADVANCED LAUNCH CONTROL COMPUTER SYSTEM 
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FIGURE 3.7. 1-3. TECHNOLOGY MATRIX: GROUND SYSTEMS 


Recommendations: 

• LPS is recommended as the main Launch Support System for the Near Term 
HLCV (SDV-2ES) 

- LPS was designed to support the Shuttle 

- HLCV (SDV-2ES) will maintain Shuttle ground interfaces (H/W & S/W) 

• LPS is already in place and functional 

- HLCV (SDV-2ES) ground and launch processing software will be a subset 
of current Shuttle software 

• Trade Ground System Evolution 

- Near Term additions vs. Far Term vehicle autonomy 
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3.8 System Architectures 

Vehicle and Ground Based Testbed architectures were analyzed in the context of the Heavy 
Lift Cargo Vehicle study objectives. The HLCV functional requirements formed the basis for 
the selection criteria in both the hardware and software architectures. 

3.8.1 Vehicle Architectures 

Figure 3.8.1 -1 shows three of the fault tolerant system architectures considered and some of 
their more important characteristics. The three shown include an asynchronous, multi string 
system, a loosely coupled system with shared CPU, and a synchronous, fully distributed, 
system that featured an open architecture. 

Figure 3.8. 1-2 shows an example of an MPRAS, (Multi Path, Redundant Avionics Suite), type 
architecture. The MPRAS type architectures are being considered for use in the Advanced 
Launch System, (ALS) because, in part, of their ability to include Integrated Health 
Monitoring, (IHM), and Expert System technology. 

The Asynchronous system was chosen for the Phase 1 HLCV system for several reasons. 
Availability, expansibility, performance and cost effectiveness were the primary factors that 
swung the choice from a Shuttle Orbiter based system. 

The MPRAS architecture was chosen for the far term vehicles. The cost savings associated 
with the IHM and Expert System technology to be included with the MPRAS architecture is 
the subject of the following sections. 
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FIGURE 3. 8. 1-1. FAULT TOLERANT SYSTEM ARCHITECTURES 
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FIGURE 3. 8. 1-2. MPRAS 


3. 8. 1.1 Integrated Health Monitoring 

Figure 3.8. 1.1-1 shows the goals of the IHM architectural designs. The GBT is designed to 
phase in the additional support for the IHM technologies during Phase 2. Some of the 
technologies are allready scheduled for demonstration and are shown in Figure 3. 8. 1.1 -2. 
Figure 3.8.1. 1-3 shows some areas in which IHM can reduce the costs during testing. 
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• Data analysis 
knowledge acquisi- 
tion system 


FIGURE 3.8.1 .2-1. AREAS IN WHICH EXPERT SYSTEMS WILL BE BENEFICIAL AND VIABLE. 


3. 8. 1.3 GBT Architecture 

The GBT software and hardware architectures evolved from the functional requirements, 
GDSS base of experience and selected analysis of available hardware and software. Figure 
3.8.1. 2-1 summarizes the GBT functions. The architecture must accommodate these 
functions in harmony with the GBT philosophy and objectives. 
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INPUTS 


TEST & EVALUATION 
FEATURES 

• SELECTABLE TEST 
ENVIRONMENT 

- Mission Phase 

- Vehicle Dynamics 


Individual Concepts \ 
Architecture CandidatesN 
Design Alternatives 
New Applications y 
Alternate Test Methods/ 



CONFIGURABLE 
* H/W & Systems 
Interfaces 
- Avionics System 
Simulation Testing 


STAND ALONE 
- Component 
Benchmark Tests 



FUNCTIONS 


SIMULATION 
CONTROL & MONITOR 


TEST/EVALUATION 

SIMULATION 


DATA STORAGE 


PRODUCTS 

& 

SOLUTIONS 


Integrated Systems 
Selected Architecture 
Selected Design 


ANALYSIS RETRIEVAL Appr0Ved AppilCatl0n 
ANALYSIS, Ht I HlbVAL Se , 0Cted Test Method 


TEST RESULTS 
DEMONSTRATION & 
DOCUMENTATION 



FIGURE 3. 8. 1.3-1. GBT FUNCTIONS 


3.9 Data Buses & High Speed Networks 

Closed-loop, real time, high fidelity simulations are basic to GBT success. The proper 
selection of data busses and high speed networks for data transfer and sharing between GBT 
elements not only required establishment of throughput but also a survey of currently 
available products. Figure 3.9-1 shows the four basic types of busses in the GBT. Phase 1 
bus selection includes 1553 for the vehicle bus, ProNet 80 for the communications and 
control bus and VME Bus for the DMA bus. 



FUNCTION - Simulates Vehicle Systems and Maintenance Bus Traffic/Operations 

• 1553 - 1 MBS 

• 1773 FIBER-OPTIC - 1 MB/S 

• FUTURE BUSSES- HSDB , ETC 50 MB/s 


INSTRUMENTATION BUS 




FUNCTION - Simulates Vehicle Instrumentation and Sensor Busses 
• Speed - 1-100 MB/S 


COMMUNICATION & CONTROL BUS 


FUNCTION - Data Transfer and Simulation Control 
• Speed - 80 MB/S 


HIGH SPEED /DMA BUS 


FUNCTION - Processor to Processor Data Sharing 
• Speed - Processor Dependent (2.5 GB/s - Butterfly) 


FIGURE 3.9-1. GBL BUS CLASSIFICATIONS 
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3.10 Instrumentation - Data Acquisition Technologies 

The following outline lists the architectural features of a current avionic instrumentation 
system in launch vehicles: 

• Digital Interfaces 

- Flight computer interface via data bus 

V One way data flow (computer — > telemetry) 

- Spacecraft data interleaving is common 

- MIL-STD-1553 interface 

- Master Unit - remote unit interface typically on proprietary bus 

• PCM Outputs 

- Tailored for specific application 

- Error detection/correction coding (i.e., Reed Solomon/Convolutional) 

• Piece parts 

- S-level parts are not readily available for some applications 

V Gate arrays 

V Phase lock loop 

V EEPROMS 

• Signal Conditioning 

- Software programmable gains and offsets 

- Multiplexed signals share signal conditioner circuitry 

- Multiplexed transducer excitation 

• Digital Signal Processing 

- Low pass (anti-aliasing) filtering 

- Power spectral density (PSD) 

- Fast fourier transformer (FFT) 

- Transient recording 

• Control Logic 

- May be processor based or hard logic driven 

- Extensive use of gate arrays 

- EEPROMS used for remote programming 

- Limited radiation/single event upset hardening 

Data Acquisition Technologies - Near Future 

• Digital Signal Processing 

- Programmable general purpose DSP modules 

- Data compression 

- On-board data analysis 

- Built-in-test 

• Control Logic 

- Most systems will use some form of processor 

- System can be configured with "dumb" or "smart" remote units 
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• Digital Interfaces 

- Redundant reconfigurable MIL-STD-1553 data bus interface 

- Two way data communication with flight control system 


• PCM Outputs 

- Encryption on a chip eliminates need for external encrypter with interface 
unit 



Compatability 

Availability 

Risk 

Cost 

Performance 

USE 

Rating 

Air 

Ground 

Lab 

FDDI 

Excellent 

Near 

Moderate 

High 

Excellent 

V 

V 

V 

Excellent 

HSDB 


Near 

Moderate 

High 

Very Good 

V 


V 

Good 

IEEE802.3 

Acceptable 

Now 

Low 

Low 

Good 


V 

V 

Acceptable 

IEEE 802.4 


Now 

Moderate 

Low 

Good 


v : 

V 

Acceptable 

IEEE 802.5 


Now 

Moderate 

Low 

Good 


V 

V 

Excellent 

1553 

Excellent 

Now 

Very Low 

Low 

Poor 

V 


V 

Good 

1773 

Excellent 

Now 

Low 


Poor 

V 



Acceptable 


FIGURE 3.10-1. TECHNOLOGY MATRIX: DATA TRANSFER 


Recommendations: 


• Select Fiber Distributed Data Interface (FDDI) or High Speed Data Buss (HSDB) 
for near term 

- Both use fiber optic media for high data rates, excellent EMI immunity, low 
signal loss, and low weight 

- Both are designed to be fault tolerant 

V The FDDI Standard System uses 4B/6B encoding techniques and the 
latest hardware technology to handle a 100 MBPS data rate 

V HSDB uses the Manchester encoding technique (which is 30% less 
efficient) and more readily available hardware to produce a 50 MBPS 
data rate 

• FDDI should be selected in multiple processor ring applications 

• Modifications to FDDI will be necessary for linear applications 

• For lower cost, near term, high speed linear applications, HSDB 
should be used 

3.10.1 GBT Instrumentation Systems Support 


The original concept of the GBT Avionics Hardware Testbed provided most of the required 
interface capabilities to support instrumentation system operational testing and evaluation. 
Lacking was the ability to fully evaluate the downlink data. The instrumentation segment was 
added to the GBT to permit end-to-end evaluation of HLCV telemetry systems. Section 6 
describes the GBT architecture and the function of the instrumentation element. 
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3.11 GBT Main Processor Selection 

With the shift of emphasis to design of the GBT, selection of the primary lab processor took on 
added importance. The scope of the trade study used to determine the performance 
characteristics of this unit and the attendant survey of potential vendors required a special 
effort. A technical demonstration was conceived that would permit a performance 
comparison of those processors and their software tools thought capable of fulfilling the basic 
requirements. The test would involve tasks similar to those planned for the GBT and use 
programs supplied by both the customer and GDSS. 

The initial selection process of potential processors considered about 20 candidates. Figure 
3.1 1-1 shows some of the selection criteria and the candidates that fulfilled the criteria. The 
"paper study" was followed up with a head-to-head performance comparison. Three 
benchmarks were selected to evaluate the processors and their attendant software tools. 

The first benchmark was from MSFC and was a mature Fortran coded model of the SSME. 
The second was provided by GDSS and was a modular model of the ALS avionics system 
coded in "C". The third benchmarks were industry standards chosen by the participants. 

The final phase of the tech demo has been extended to include additional processors for 
evaluation. A detailed review of the initial study and a complete analysis of the performance 
test results will be reported in the Final Report Addendum. Also included will be the analysis 
that lead to the ultimate selection of the Concurrent Goldrush series computer. 
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CUT 1. REAL-TIME OPERATING SYSTEM 


Alliant Computer Systems Corp. 
BBN Corp. 

Concurrent Computers Corp. 

Elxsi Corp. 

Flexible Computer Corp. 

Gould Inc. 

Harris Corp. Computer Systems Division 
NCube Corp. 



CUT 2. GLOBAL/SHARED MEMORY SUPPORT 


CUT 3. SYSTEM THROUGHPUT 150 MIPS 
SYSTEM SCALABLE 


CUT 4. COST 


Alliant Computer Systems Corp. 
BBN Corp. 

Concurrent Computers Corp. 
Elxsi Corp. 

Flexible Computer Corp. 



BBN Corp. 

Concurrent Computers Corp. 
Elxsi Corp. 



BBN Corp. 

Concurrent Computers Corp. 


FIGURE 3.11-1. SELECTION CRITERIA/CANDIDATES 


4.0 REQUIREMENTS 

Section 4.0 identifies the Phase I GBT requirements and the vehicle support requirements 
from which they were driven. Phase II and full-up target phase driven requirements are 
covered only incidentally. A shift toward designing a phased GBT was directed by the 
customer after the reference HLCV avionics systems had been conceptually designed and 
sized sufficiently to determine the requirements of a supporting development and evaluation 
lab.This GBT would accommodate integrated, real time, testing and evaluation of generic 
HLCV era avionic systems and line replaceable units (LRU'S) To this end, a Preliminary 
Design Document (PDD) was generated that contained details of a Phase I GBT. The lab 
was structured for growth and sized with hooks for future phases. The core processor, as an 
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example, was initially sized to handle operations beyond the ascent, on-orbit maneuver and 
de-orbit of the Phase 1 , Shuttle derived reference vehicle. The processor chosen can 
accommodate a Phase 2 vehicle and has planned expendability to easily accommodate 
vehicles beyond the far term, Target vehicles.The Avionics Hardware Testbed and its 
supporting software will also accommodate the growth of technology and handle all three 
phases of expansion. 


4.1 GBT Functional Requirements 

The requirements to which the GBT must respond fall into three general categories: 

Program Driven requirements include such things as vehicle dynamics, mission 
profile/timelines and vehicle avionic system architecture. The second general category, 
Technology Driven requirements, include design problem areas that are not meeting 
performance criteria or are limiting system efficiency or upgrade. The last general category of 
functional requirements is Facility/Resource Driven requirements. These requirements 
are related more to the physical aspects of the test facility itself and the limitations of the 
resource equipment used in testing. 


4.2 Program Driven Requirements 

The GBT was conceived to provide support to new vehicle/spacecraft programs primarily 
before their respective Preliminary Design Reviews, (PDR's), or when the nature of the 
required support was beyond the capabilities of their local, dedicated facilities. Figure 4.2-1 
outlines some of the requirements associated with these vehicles and their mission profiles. 
Some of the many program driven issues are: 

• Inertial navigation unit must meet specification required to navigate to Space 
Station and dock within Space Station contract constraints 

- Axial closing velocity .2 fps max 

- Lateral velocity ± .0 fps 

- Angular velocity ± .05 deg/sec roll 

± .15 deg/sec lateral 

• Payload support required for Centaur G using payload GSE 

• The Avionics system reliability and redundancy 

• Support successful de-orbit (Phase II) with a planned ocean impact of surviving 
parts 

• Use best of available, mature avionics components from STS and other 
applications where cost and risk effective 
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Vehicle 

Shuttle C 

ALS Core 

ALS LRB 

FRWB 

Reusability 

SRB‘s 

None 

BRM 

Full Reuse 

IOC 

TS55 

- T53S 

TtJ99 

2002 

Engines 

3 + 2 SRB 

3 

7 

6 + 6 A/B 

Man Rating 

TSD 

0.99981 

0.99995 1 

TBD 

Reliability 

Cargo carrier 
Prox OPS & De-orbit 

Deorbit to ocean. 
FO/FS Manned Cargo 

Sub-orbital 
FO/FS Manned Cargo 

Return & Landing 
FO/FS Manned Cargo 



Lore de-orDit 
T + 98 min. 

i + 

162 seconds 

Less than 
1 hour 



Many 

Many 

Many 

Number of Vehicles 

Moderate 

Many 

Many 

Few 




UNIS 

UNIS 


IPS 

Expert System App 

Expert Systems App. 

Near Autonomous 

P/L and Vehicle l/F’s 


None 

None 

None 

Vehicle 

Management 


wmm gwjiyE Et 

Controlled from 
Core 

Near Autonomous 
Manual Backup 

Rendezvous & 
Docking 

OMV Assisted 

None 

None 

None 

Data Flow 


HcV£McflHK2-j£H| 

Interface to 
Core 

GN&C3 • <10 MBPS 
Instru 1 - 320 KBPS 

Processing 

300 KOPS 

m 

Share core CiN&u * 
3 ropulsion 7 @ 1 MIPS es 
Share core Instru 
Miscellaneous <1 MIPS 

CiN&C 3 (a> 6 MIPS 
Propulsion 6 @ 1 MIPS 
Instru 1 @ 3 MIPS 
Imaging 10 MIPS 
Miscellaneous <2 MIPS 


FIGURE 4.2-1 HLCV AVIONICS REQUIREMENTS 


4.2.1 Phase 1 (STV, Shuttle C, SDV 2ES) 

The HLCV expendable booster, (SDV-2ES), Shuttle-C, and Space Transfer Vehicle (STV) 
developmental programs are the basis for the Phase 1 GBT functional requirements. Shuttle- 
C was agreed upon to serve as the forcing function for the Phase 1 lab. The functional block 
diagram for this three-string avionics system is shown in Figure 4.2.1 -1 . The Program 
requirements that drove the avionics system design are listed below. 

Shuttle-C Program Requirements; 

• First flight = 1994 

• Low DDT&E and cost 

• Maximum utilization of STS and other flight proven hardware systems 

• Maximum utilization of existing STS test and launch facilities 

• Simplified ground and flight operations 

• 2-3 flights per year for 1 0 years (access impact of up to 6 flights per year) 

• Unmanned cargo vehicle (manrated) 

• Expendable cargo element 

• Minimum performance of 100 LKB to 220 nm/28.5 degrees 

• Minimum payload envelope of 15 x 60 feet 

• 100% SSME power level 

• High reliability and system resiliency 

• Payload interchangeability with STS 

• On orbit control and Space Station docking to utilize OMV to maximum extent 
possible. 
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DATA BUS 
ISOLATION 
AMPLIFIER 1 A 2 


RVU 

MEC A P/L 


NTERFACS BUS 


MAIN 

ENGINE 

INTERFACE 

UNIT 


REACTION 

JETS 

r (PER POO) 



FIGURE 4. 2. 1-1. SHUTTLE-C AVIONICS BASELINE 


VEHICLES 

- PERFORM AVIONICS ANALYSIS/SIMULATION TO VERIFY RE-TEST AND RE-USE CAPABILITY OF FRWB AND 
BRM MULTI-MISSION AVIONICS 

• LAUNCH PROCESSING AND VEHICLE MANAGEMENT 

- PROVIDE THE PROCESSING THROUGHPUT AND MEMORY CAPACITY FOR EXPERT SYSTEM APPLICATION 
DEVELOPMENT OF BOTH LAUNCH PROCESSING AND ON-BOARD MISSION MANAGER 

• RENDEZVOUS AND DOCKING 

- PROVIDE A 3D DISPLAY PROCESSING CAPABILITY FOR SHUTTLE C CARGO CARRIER/ OMV/ SPACE 
STATION. PROVIDE A FUTURE CAPABILITY IF ALS CORE DEVELOPS THIS TYPE OF MISSION 

• IOC 

- 1 994 SHUTTLE C PROVIDE PROVISIONS FOR SIMULATING MODIFICATIONS TO EXISTING H/W AND S/W 

- 1997 ALS REQUIRES EXPENDABLE CAPABILITY AS ALS SOFTWARE IS EXPANDED 

- 2000 FRWB WIDE CAPABILITY 

• MANRATING 

- SHUTTLE C CARGO CARRIER FO/FS FOR SPACE STATION PROXIMITY OPERATIONS. DIFFERENT CARGO 
CARRIER FOR INJECTION MISSIONS? 

- ALS CORE FO FOR DE-ORBIT, FO/FS FOR MANNED CARGO 

- FRWB FO/FS FOR FLYBACK AND LANDING. FO/FS FOR MANNED CARGO 

- HLCV GBT SIMULATE REDUNDANCY PROVISIONS TO MEET ABOVE GOALS 


ENGINE SYSTEM INTEGRATION 

- 3 SHUTTLE C, 10 TO 14 ALS FUTURE SYSTEMS 

- TVC ENGINE CONTROL INTEGRATION (~1 MIPS PER ENGINE) 

- SIMULATE ARCHITECTURE PARTITIONING FOR BRM RECOVERABLE AVIONICS 


FIGURE 4.2. 1-2 PROGRAM DRIVEN ISSUES 
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DISCRIMINATING 

CHARACTERISTICS 

DESIGN REFERENCE MISSIONS 
(DRM'S) 

PERFORMANCE REFERENCE 
MISSIONS (PRM'S) 

(1) UNMANNED 
SPACE STATION 
ASSY W/OMV 

(2) ORBITAL 
DEPLOY 

(3) SUB- 
ORBITAL 
DEPLOY 

(1) POLAR 
LAUNCH 
FROM ETR 

(2) POLAR 
LAUNCH 
FROM WTR 

LAUNCH SITE 

ETR 

ETR 

ETR 

ETR 

WTR 

SECURE 

NO 

POSSIBLY 

POSSIBLY 

POSSIBLY 

YES 

INCLINATION 

28.5’ 

28.5'-63.5‘ 

28.5* 

98.7' 

98.7’ 

RENDEZVOUS & PROX OPS 

YES 

NO 

NO 

NO 

NO 

REFERENCE ALTITUDE 

220 nmi 

110 nmi 

>100 nmi 

100 nmi 

100 nmi 

DOCK/BERTH 

YES 

NO 

NO 

NO 

NO 

ON-ORBIT STAY TIME 

APPROX. 14 DAYS 

1 DAY 

UNSPECIFIED 

<2-1/2 HR 

<2-1/2 HR 

CIRCULARIZATION 

YES 

YES 

NO 

YES 

YES 

PAYLOAD DEPLOYED 

NO 

YES 

YES 

YES 

YES 

PAYLOAD EXTRACTED 

YES 

NO 

NO 

NO 

NO 

MANNED PRESENCE 

YES 

NO 

NO 

NO 

NO 

MIXED CARGO 

YES 

POSSIBLY 

NO 

POSSIBLY 

POSSIBLY 

OMV 

YES 

POSSIBLY 

NO 

NO 

NO 

MINIMUM INJECTED WEIGHT 
@ REFERENCE ALTITUDE 

100,000 LB 

80,000 LB 

100,000 LB 

TBD 

TBD 

INSERTION 

DIRECT 

STANDARD 

SUBORBITAL 

UPSPECIFIED 

UNSPECIFIED 


FIGURE 4. 2. 1-3. SHUTTLE C MISSION REFERENCES 


4.2.2 Phase 2 (ALS Core, ALS Booster, SDV 2RS) 

The Phase 2 IOC is set for August 1992. The Phase 2 GBT support capabilities will be 
extended to include the ALS Core and Booster, SDV-2RS, and the upgraded Shuttle-C. 
Since the ALS Core and Booster closely fit the SDV-2RS functional requirements, they were 
chosen for the reference vehicles for the Phase 2 GBT. Figure 4.2.2-1 through 4.2. 2-3 show 
the ALS Core and Booster avionics systems and the associated vehicle processing 
requirements. Figure 4. 2. 2-4 associates the ALS Core throughput requirements with its 
design reference mission timeline. 
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AVIONICS DETAILED BLOCK DIAGRAM 



AEROSPACE GROUNO EQUIPMENT AGE 
INERTIAL NAVIGATION UNIT 
LASER FIRING UNIT 
MASTER OATA UNfT 
POWER CONTROL UNIT 
REMOTE DATA UNIT 
RATE GYRO UNfT 
REMOTE VOTER UNIT 
TELEMETRY WTERFACE UNfT T1U 

THRUST VECTOR CONTROL TVC 


FIGURE 4.2.2-1 ALS AVIONICS & POWER SYSTEMS 



ALS CORE 



[ WITH LIMITED EXPERT SYSTEMS 

SUBSYSTEM (WITH 
HEALTH MONITORING) 

THRUPUT 

(MIPS) 

[DIAL 

MEMORY 

(MBYTES) 

I/O 

DATA RATE 
(MBPS) 

I/O 

DEVICES 

(QUANTITY) 

PROPULSION 

3 

(IMIPS/ENG) 

0.286 

0.375 

819 

FLUIDS 

<0.1 

<0.1 

0.216 

241 

POWER 

<0.1 

<0.1 

<0.01 

100 

* INSTRUMENTATION 

<3 

<0.002 

0.256 

1500 

GN&C (ADAPTIVE) 

4.063 

0.988 

0.153 

600 

SYSTEMS SOFTWARE 

0.21 

0.59 

-- 

- 

COMMUNICATIONS 

<0.1 

<0.1 

<0.01 

100 

VEHICLE ELEMENT 
INTERFACE 

<0.1 

<0.1 

0.072 

262 

TOTAL 

10.47 

2.06 

1.09 

3622 

SHUTTLE 

COMPARISON 

0.343 

0.42 

NA 

-4000 


ff INCLUDES SENSOR PROCESSING NOT 


NOTE: THE PROCESSING REQUIREMENTS 


COVERED UNDER THE OTHER SUBSYSTEMS. DO NOT INCLUDE ANY ALLOWANCE FOR 
NOTE: REDUNDANCY INCLUOED ONLY WHERE MARGIN, OR FAILURE TOLERANCE. (EXCEPT 


KNOWN (E.G., PROPULSION) 


FOR PROPULSION) 


FIGURE 4.2.2-2 ALS CORE PROCESSING REQUIREMENTS 
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FIGURE 4. 2. 2-3 ALS LRB PROCESSING REQUIREMENTS 



LIFT- 

LRB 

MAX 

LCEE 

PAYLOAD 

END OF 

OFF 

SEPARATION 

0 

SHUTOFF 

SEPARATION 

MISSION 


FIGURE 4.2.2-4 ALS THROUGH-PUT REQUIREMENTS 
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4.2.3 Target (FRWB, FRWB, PRCV) 

The Phase 3 or Target configuration IOC has not been set, but if it is tied to the Fully 
Recoverable Wing Booster (FRWB), and the Partially Reusable Cargo Vehicle (PRCV) 
programs, it should be in 1996 to 1998. 

Figure 4.2. 3-1 outlines the Processing Requirements for the FRWB while Figure 4. 2. 3-2 
associates the throughput requirements with the FRWB mission timeline. The FRWB avionics 
system is designed to be fully autonomous from launch to landing and roll out. The GBTs 
capability to support FRWB and PRCV development must start long before the 1996-1998 
IOC. The GBT functions must include FRWB/PRCV related inputs in both Phase 1 and Phase 
2. Typical of these inputs are: 

(1) Electromechanical Actuator applications in vehicle aero control and Thrust Vector 
Control systems; 

(2) Redundancy Management using Expert Systems and a distributed processing 
system; and 

(3) An autonomous, robust GN&C system capable of near all-weather launches and 
minimum tailoring of software mission to mission. 


These technology driven requirements are discussed in the next section. 


FULLY REUSABLE WINGED BOOSTER (FRWB) 



WITH LIMITED EXPERT SYSTEMS 

SUBSYSTEM (WITH 
HEALTH MONITORING) 

THRUPUT 

(MIPS) 

TOTAL 

MEMORY 

(MBYTES) 

I/O 

DATA RATE 
(MBPS) 

I/O 

DEVICES 

(QUANTITY) 

‘PROPULSION 

6 

(IMIPS/ENG) 

■m 

06 


FLUIDS 

<0.1 

<0.1 

0.32 

380 

POWER 

<0.1 

<0.1 

<0.01 

180 

# INSTRUMENTATION 

<3 

0.0048 

0.320 

4000 

GN&C (ADAPTIVE) 

5.199 

1.264 

0.394 

1225 

SYSTEMS SOFTWARE 

0.24 

0.79 

- 

-- 

COMMUNICATIONS 

<0.1 

<0.1 

<0.01 

120 

VEHICLE ELEMENT 
INTERFACE 

<0.1 

<0.1 

0.0256 

5 

TOTAL 

14.64 

3.42 

1.67 

9174 

SHUTTLE 

COMPARISON 

0.343 

0.42 

NA 

-4000 


* PROCESSING IS TIME SHARED 
BETWEEN BOOSTER ENGINES 
ANO AIR BREATING ENGINES. 

# INCLUDES SENSOR PROCESSING 
NOT COVERED UNDER OTHER 
SUBSYSTEMS. 

NOTE : REDUNDANCY INCLUDED ONLY 
WHERE KNOWN (E.G., PROPULSION). 


NOTE: THE PROCESSING REQUIREMENTS 
DO NOT INCLUDE ANY ALLOWANCE FOR 
MARGIN, OR FAILURE TOLERANCE (EXCEPT 
FOR PROPULSION). 

NOTE : THE PROCESSING REQUIREMENTS DO 

NOT INCLUDE THE IMAGING SENSOR 

PECULIAR PROCESSING WHICH IS 
ASSUMED TO BE SELF CONTAINED. 


FIGURE 4.2. 3-1 . FRWB PROCESSING REQUIREMENTS 
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131 - 


12L 


INCLUDES HEALTH MONITORING. 
INCLUDES REDUNDANCY WHERE KNOWN. 
NO MARGIN ALLOWANCE. 


T 

H 

R 

U 

P 

U 

T 

(MIPS) 


iiL 



9 


PROPULSION 

{INCLUDES ENGINE 
OUT CAPABILITY) 




GN&C (ADAPTIVE) 




S W I LM SOT I 




PRE- 

LAUNCH 

C/O 


[TERM INAL| 
COUNT- 
DOWN 


"lift- 

off 


OTHER 


MAX LflB FRWB FBE MSBLS TOUCH - 

Q SEPARATION RE-ENTRY GNITON ACQUISITION DOWN 


ROLL- 

OUT 


END OF 
MISSION 


FIGURE 4. 2. 3-2. FRWB THROUGH-PUT REQUIREMENTS 


4.3 Technology Driven Requirements 

Several pacing technologies were investigated during the initial stages of this study. Each 
was associated with their specific application on the HLCV era avionics systems and 
prioritized as to their role in achieving the design goals. The following paragraphs show the 
impact on the GBT design. 

4.3.1 System Architectures/Redundancy Management 

One of the most fundamental drivers of the GBT processing/throughput requirements involves 
the basic vehicle architectures to be simulated and the operational environment in which they 
must be tested. The basic Phase 1 through the complex Target GBT configuration had to be 
sized to full-up, end-to-end, real-time vehicle system simulations. This translates into a 
throughput requirement for the lab of about 150 million instructions per second (MIPS) for the 
Phase 2 GBT. The processor assigned to model the system architecture had to be able to 
model a parallel, distributed, multi-string system; duplicate the redundancy management 
logic of that system and be able to monitor, control and provide external stimuli to the system 
under test. The FRWB avionics system is fully autonomous and, therefore, includes 
Integrated Health Monitoring (IHM), and a high precision launch to launch GN&C system that 
may incorporate a multi-spectral Image Processing System. Much of the traditional GSE 
functions will be performed by the FRWB system. All these factors will drive the GBT 
throughput and parallel processing capacity well beyond the 150 MIPS of the Phase 2 lab. 
This mandates a main processing capacity which can be expanded incrementally without 
having to replace the original equipment. 
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4.3.2 Power Distribution, Conditioning and Management 

The HLCV era vehicles are required to perform over a wide ranging series of missions that 
last from 90 minutes to several months. The reliability required of the supporting power 
systems plus the new demands of cost effectiveness have driven a re-examination of 
traditional solutions and a search for new designs. The increasing demand for power by 
electromechanical actuators and the new designs being utilized in their attendant power 
supplies have elevated this once stable design area into new activity. The GBT power 
extension will be able to evaluate alternate power sources (batteries, fuel cells and solar 
cells), power distribution system architectures, redundancy management schemes, and 
different methods of power conditioning and management. 

4.3.3 Electro Mechanical Actuators 

The clustered rocket engines of many of the HLCV vehicles have accelerated development of 
fast response high power (> 50 hp) electromechanical actuators. The HLCV GBT will support 
this effort in Phase 2. Development will be in the power supply design as well as that of the 
basic actuator. 

The integration of actuator development and testing in the total vehicle development program 
involves several areas. The end-to-end testing would, in its highest fidelity mode, require the 
actuator under test to be dynamically loaded. This loading would be controlled in part by 
inputs from the missions environmental and vehicle dynamic models. The dynamic load cell 
and its attendant support equipment could represent a prohibitively high investment. Use of 
existing or dedicated actuator labs may prove the most cost effective method of providing this 
resource. A high data rate, broadband data link to the GBT could be used in closed loop 
testing. EMA power supply development could be accommodated in the GBT Power 
Systems extension. 

4.3.4 Adaptive Guidance, Navigation & Control 

HLCV traffic models force a more robust launch capability. Not only do vehicles have to be 
easy to process and launch, they must be strong enough and smart enough to handle less 
favorable environmental conditions. Supporting Adaptive Guidance, Navigation & Control 
would include everything from concept evaluation through sensor design testing. Primary 
impact of this technology support by the GBT would be in the area of software development, 
and attendant processor capacity and flexibility. Special software analysis tools will be 
required in the investigation of various load relief concepts, sensor applications and vehicle 
dynamic control modeling. 

4.3.5 Image Processing 

The application of image processing to HLCV functions seems particularly attractive in the 
areas of rendezvous & docking and approach & landing. The delays and subsequent risks 
involved in the remote docking techniques used in OMV can be potentially mitigated with a 
"smart" docking system. Such a system could be used on the STV or retrofitted on the OMV. 
Use of image processing to detect/identify the target, its range and orientation are well within 
current state-of-the-art capabilities. Application in the FRWB approach & landing functions is 
another application to be investigated. 
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Impact to the GBT design would include software tools required for high fidelity 3D Target 
modeling and animation. Hardware requirements would include prototype sensors, TV 
camera, large, high resolution graphic monitor and an image processing workstation. 

4.4 Reference Vehicle Avionics Equipment 

The Shuttle-C Option C Avionics system was used as the reference for the GBT Phase I 
design. This section provides a detailed description of this system. 

4.4.1 Shuttle-C Option C Hardware 

• The Shuttle-C, Option C avionics system uses existing Centaur based components 

• Flight hardware and software delivered on a single pallet 

- Integrated Avionics Module (1AM) delivered with tested flight software and 
ground check-out software 

- Simple functional and contractual interfaces 

• Duplicate Systems Integration Lab (SIL) and Software Development Lab (SDL) 
delivered to MSFC for independent IV&V 

- All tools have been proven on the Centaur program and are existing and in 
use today 

• Ground hardware interfaces are unchanged, ground software changes will be 
limited to application packages. 

4.4.2 Shuttle-C Proposed Software 

• Flight Software 

- All flight software will be coded in Ada 

- Ada production tools are in place and in use at GD today for Centaur 
software production 

- Centaur Software Development Lab (SDL) provides for code development, 
generation, verification and validation 

-- The SDL includes complete Flight Analogous Software Testing (FAST) 
capabilities 

• Ground Software 

- Centaur modern avionics requires minimal changes to existing LPS 
software 

- Changes are only to the console checkout software 

• All software will be developed and validated in the SDL and verified end-to-end 
using the avionics systems integration lab in a closed-loop, flight simulation 
environment. 

4.4.3 Shuttle C Avionics Components 

4. 4. 3.1 Inertial Navigation Unit 

VENDOR: Honeywell PRIME: General Dynamics 

MASS: 55 lbs. DIMENSIONS: 17.51" x 1 1 .06" x 8.0" (L x W x H) 

POWER: 28 V/DC Input/Max Consumption = 155 W Under Flight 

MAJOR COMPONENTS: The INU shall consist of the following major subsystems: 
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A. Inertial Measurement System: Three axis strapdown system containing 
accelerometers and ring B laser gyros plus electronics (processor*, memory, I/O, etc.) 
to perform inertial measurements compensation, alignment, attitude integration, and 
filtering. 

B. Flight Control Subsystem: 1750 processor, memory, memory management and I/O 
provisions necessary for vehicle and ground systems interfaces. 

INTERFACE DEFINITION: 

• MIL-STD-1553 Serial Control Data I/O (3). 

• Inertial Processor to Flight Control Processor Internal Communication is DMA. 

• Flight Control to Inertial Processor is 1553. 

• Other unique I/O can be accommodated. 

• Cross strap ports for redundant configuration. 

PERFORMANCE: (IMS) 

• Modes: Simulation IMS Test "A" & "B", alignment, inertial, BIT. 

• Autonomous AZ align accuracy within 270 Arcsec (3- Sigma) in 45 minutes. 

• Autonomous level align accuracy within 30 Arcsec (3- Sigma) in 45 minutes. 




Laser Gyro 

GDSS 




Parameter 

(Compensated, 
Max 3 sigma) 

Specification 
(3 sigma) 

Units 



Random Walk 

0.0035 

0.006 

deg/rt hr 



Bias Stability 

0.006 

0.01 

deg/hr 



SF Uncertainty 

10.0 

15.0 

PPM 



SF Asymmetry 

4.0 

5.0 

PPM 



(3 deg/sec) 






IA Stability 

10.0 

15.0 

arc- sec 



PERFORMANCE: (FCS) 

• CPU shall be CMOS/SOS 

• Bit error rate due to Single Event Upsets less than 10-7/hr at geosync altitude. 

• MIL-STD-1750 Instruction Set throughput shall be a minimum of 1 MIPs. 

• Memory shall have a minimum addressing capability of 256K words. 

ENVIRONMENTAL COMPATIBILITY 
OPERATIONAL 


• MIL-STD-1540 

• Temperature: 

• Humidity: 

• Pressure: 

• Acceleration: 

• Galactic Cosmic: 

RELIABILITY: 

• MTBF: 


Qualified 
-11 to +1 40°F 
0 to 100% 

0.1 psig 
10g 

<1 0-7/hr SEU and no latch-up. 


75,000 Hours 
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COMPATIBILITY WITH OTHER SYSTEMS: 

• Titan/Centaur 

• Atlas/Centaur 

• Shuttle C 

• ALS 

• ASPS 

AVAILABILITY: 

• (TC-12) First flight unit delivery 02-15-90/First flight on A/C 4/1/91 



TEMPERATURE 


MIL-STD-1553 BUS 


ANALOG OUTPUTS' 

| MIL-STD-1553 BUSES 
] SIU INVERTER REF* 
|SCU CM D/STROBE* 

DATA XFR PORTS (OUT) 
(FOR REDUNDANT 
CONFIGURATION) 


•CENTAUR UNIQUE INTERFACES THAT CAN 
BE REMOVED/REPLACED 


FIGURE 4.4.3.1-1. INU FUNCTIONAL INTERFACES 
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FIGURE 4.4.3. 1-2. INERTIAL REFERENCE UNIT PACKAGING OUTLINE 
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4. 4. 3. 2 Data Aquisition System (DAS) 

VENDOR: PRIME: 

MASS: MDU 10 lbs DIMENSIONS: 

RDU 10 lbs 

POWER: 

4. 4. 3. 2.1 Data Aquisition System Functions 

A. The Shuttle C telemetry system monitors the safety and performance of all vehicle 
subsystems. A wide variety of signal types are received and processed including 
acceleration, vibration, temperatures, pressures, currents and voltages, tachometer 
signals and discretes. 

B. The heart of the telemetry system is the data acquisition system (DAS), made up of a 
master data unit (MDU) and two remote data units (RDU’s). The DAS provides the 
capability to monitor several hundred unique vehicle parameters in addition to 
guidance and navigation and spacecraft data prior to launch and throughout all 
phases of flight. 

C. The DAS, which will be developed and qualified for first use with the commercial 
Atlas/Centaur program, has a high potential for implementation on all launch vehicles 
produced by General Dynamics Space Systems Division. The system design 
provides increased flexibility and performance at reduced cost and weight. 

D. The MDU provides transducer excitation, signal conditioning and encoding for all front 
end measurements in addition to receiving and formatting data from the spacecraft, the 
digital computer unit (DCU) and two RDU's. The MDU provides two PCM outputs, one 
of which is connected to the transmitter, the other is used to provide a hardline link to 
the telemetry ground station. 

E. The two RDU's provide excitation, signal conditioning and encoding for all end 
measurements. The RDU's output this data, upon command, to the MDU. 
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INTERFACE DEFINITION (MDU): 
Digital Interfaces: 

Remote Data Unit (RDU) 
Quantity of RDU's 
Operating distance 
Bus Type 

Spacecraft PCM Input 
Input bit rate 
Signal type 

MIL-STD-1553 
Interface type 
No. of messages 
Message length 

INTERFACE DEFINITION (RDU): 
Digital Interfaces: 

Master Data Unit (MDU) 
Operating distance 
Bus type 

PERFORMANCE (MDU) 

High level analog 
Spans 
Offsets 
Filtering 

Cutoff frequency 
Sample rates 

Low level analog 
Spans 
Offsets 
Filtering 

Cutoff frequency 
Sample rates 

Resistance 

Current sources 
Spans 

Offsets (course) 

(fine) 

Filtering 
Sample rates 

Pulsed input 

Frequency range 
Sample rates 
Counter 
Vin 

Bi-Level 


up to 6, jettisonable 
up to 200 ft from MDU 
vendor specified 

up to 4 KBPS, asynchronous 
NRZL 


RT, transformer coupled 
programmable (TBD max) 
programmable (TBD max) 


up to 200 ft from MDU 
vendor specified 


8 software selectable 

250 bipolar, software programmable 

digital, low pass, FIR type 

8 software selectable 

format programmable 


8 software selectable 
250 software programmable 
digital, low pass, FIR type 
8 software selectable 
format programmable 


2, mirrored, multiplexed 
8 software selectable 
2, software selectable 
250 software programmable 
digital, low pass, FIR type 
format programmable 


determined by sample rate 
format programmable 
8 bit, reset after reading. 
0.5 to 25 V p-p 
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Logic 1 
Logic 0 

inputs/data wd 

Attenuators 
Ratio 
vin (max) 


+3 to +35 VDC 
-10 to +1 VDC 
8 


10:1 

50 VDC 


Excitation 

High level transducers 


Discretes 

Strain gauge transducers 
Potentiometric transducers 


28 VDC, 
100 mA 
28 VDC, 
10 VDC 
5 VDC 


30 mA nominal foldback protected @ 
3 mA max 


PCM Outputs 

PCM Output 1 filtered NRZL 

PCM Output 2 MRZL, BNC connector 


Bit Rates 

No of bit rates 
Bit rates 

Bit rate tolerance 


4, command selectable 
16K, 32K, 64K, 128K BPS 
01 % 


PCM Formats 
No. of formats 
Major frame length 

Minor frame length 
Word length 
Bit order 


4, command selectable 

1 to 256 minor frames, software 

programmable 

16 to 1024 words, software programmable 
8 bits 
MSB first 


Programmability 
Memory type 
Interface 
Language 

PERFORMANCE (RDU) 
High level analog, 
Spans 
Offsets 
Filtering 

Cutoff frequency 
Sample rates 


EEPROM 

IEEE-488 

TBD 


8 software selectable 

250, bipolar, software programmable 

digital, low pass, FIR type 

8, software selectable 

format programmable 


Low level analog 
Spans 
Offsets 
Filtering 

Cutoff frequency 
Sample rates 


8, software selectable 
250, software programmable 
digital, low pass, FIR type 
8, software selectable 
format programmable 
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Resistance 

Current sources 
Spans 

Offsets (course) 

(fine) 

Sample rates 

Pulsed input 

Frequency range 
Sample rates 
Counter 
Vin 

Bi-Level 
Logic 1 
Logic 0 

Inputs/data wd 

Attenuators 
Ratio 
Vin (max 

Excitation 

High level transducers 
Discretes 

Strain gauge transducers 
Potentiometric transducers 

Programmability 
Memory type 
Interface 
Language 

ENVIRONMENTAL COMPATIBILITY: 

PHYSICAL CHARACTERISTICS (MDU) 
Environments (IAT) 

Temperature 

Acceleration 

Shock 

Vibration 

Humidity 

PHYSICAL CHARACTERISTICS (RDU) 
Environments (IAT) 

Temperature 

Acceleration 

Shock 

Vibration 

Humidity 


2, mirrored, multiplexed 
8, software selectable 
2, software selectable 
250 software programmable 
format programmable 


determined by sample rate 
format programmable 
8 bit, reset after reading. 
0.5 to 25 V p-p 


+3 to +35 VDC 
-10 to +1 VDC 
8 


10:1 

50 VDC 


28 VDC, 30 mA nominal foldback protected 
@ 1 00 mA 
28 VDC, 3 mA max 
10 VDC 
5 VDC 


EEPROM 

IEEE-488 

TBD 


-40 to +70°C radiative cooling only 

±10 g 

TBD 

TBD 

± 1 00 % 


-40 to +70°C radiative cooling only 
±10 g 
TBD 
TBD 
±1 00% 
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4. 4. 3. 2. 2 Remote Voter Unit (RVU) 

PRIME: General Dynamics/Space Systems Division 

MASS: 35 lb. DIMENSIONS: 1 2.00" x 8.25" x 8" (L x W x H) 

POWER: 28 VDC Input, MAX POWER 

CONSUMPTION: 35 watts/max (80 switches ON) 

MAJOR COMPONENTS: The RVU shall consist of the following major functions: 

A. MIL-STD-1553B Bus Interface: Three independent Remote Terminal Interface Units, 
each powered by its own power supply, shall control 1 553B data flow and associated 
protocol. 

B. Control Logic: Performs majority voting of vehicle load switching information, as well 
as engine position information, multiplexes digital instrumentation data and performs 
built-in-test. 

C. Solid State Switches: 80 solid state switches provide +28VDC power to vehicle 
sequencing and safety functions, including pyrotechnic loads. Redundant +28VDC 
buses and series/parallel switch configurations shall provide single failure tolerant 
controls. 

INTERFACE DEFINITION: 

• Receives vehicle sequencing commands from the INU across three MIL-STD-1553 
avionic buses. 

• Transmits switch status and built-in-test data over all three MIL-STD-1553B avionic 
buses in response to IMU commands. (This data may be directed back to the INU or to 
the Master Data Unit (MDU). 

• Provides thrust vector control output to hydraulic servovalves (on Centaur). 

• Capable of 80 (40 prime and 40 backup) switched +28VDC discrete outputs to 
pyrotechnic and other vehicle sequencing loads. 

• Independent +28VDC power inputs (prime and backup). 

PERFORMANCE: 

• Modular construction: communications card, controller card, solid state switch cards, 
and TVC card. 

• Adaptable to single bus configuration. 

• Provides 80 dedicated solid state switch closures for up to five 16-bit switching words. 

• Throughput (from receipt of a single switching command to switched +28VDC 
unloaded output over temperature discounting bus skew): 3 MSEC max. 

• Instrumentation word resolution : 8 bits. 

• TVC word resolution: 10 bits. 

• Memory shall have a minimum addressing capability of 16K 16-bit words. 

ENVIRONMENTAL COMPATIBILITY: 

• Meets both Atlas/Centaur and Titan/Centaur temperature, acceleration, shock, 
vibration and humidity environments. 

RELIABILITY: 

• Incorporates MIL-M-38510 Class S electronics parts or, when necessary, screened 
Class B parts. 

• CMOS-epitaxial parts with frequent updating help prevent and correct for single event 
upset. 
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FIGURE 4.4.3.2.2-1. REMOTE VOTER UNIT (RVU) 
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FIGURE 4.4.3.2.2-2 RVU MODULAR DESIGN 
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4. 4. 3. 2. 3 Electrical Distribution Unit (EDU) 

PRIME: General Dynamics/Space Systems Division 

MASS: 62 lb. DIMENSIONS: 

POWER: SEE ATTACHED BREAKDOWN 

TOP LEVEL COMPONENT DESCRIPTION: 

• The EDU is a single piece of electrical equipment containing relays, contractors, 
fuses, diodes, voltage monitors, and current shunts. The EDU provides the only 
electrical power interface between Centaur, Payload and the Orbiter vehicle, with 
the exception of the Payload Centaur Aerospace Ground Equipment Power. 

DC SYSTEM DESCRIPTION COMMON TO G PRIME 

• Orbiter power input shall provide the capability to handle the following steady state 
power: 

- CISS Main Bus: Component Rating, 150 Amps at 28V DC (4.2 KW) 

- Payload Bus: Component Rating, 1800 Watt out CRU Input, 80 Amps at 25V 
DC (2000W) 

- CISS Main Bus: Thermal Capacity, 120 Amps at 28V DC (3.36 KW) 

- Payload Bus: Thermal Capacity, 1500 Watt out CRU, Input (1666.7W) 66. 7A at 
25V DC. 

• Maximum voltage drop from orbiter power interface to the CISS DC main bus and 
the payload power bus is ,95V DC. 

• Application of power to the CISS DC main bus is through a 200 amp contactor. 

• Application of power to the payload power bus is through a 1 00 amp contactor. 

• Orbiter provides four (4) Aught gauge positive wires and four (4) Aught gauge 
return wires. 

• Each positive line shall be fused with an 80 amp fuse to protect the vehicle wiring. 

• Each twenty (20) cell input shall be rated for 150 amps at 28 Volts (4.2 KW). 

• Application of power is through a 200 amp contactor. 

• Maximum voltage drop from the battery twenty (20) cell tap to the CISS DC main 
power bus is .95V DC. 

• Two (2) 4 gauge positive wires and two (2) 4 gauge return wires for each battery 
twenty (20) cell tap input. 

• Battery 1 and 2 inputs shall be in separate connectors. 

• The seventeen (17) cell input provides the following power capability: 

A. 1 50 Amps at 28V DC (4.2 KW) to the CISS DC main power bus for 
approximately 260 MX. 

B. 2.00 KW (95.3 amps at 21V DC) to the payload power bus for approximately 
260 MSEC. 

• The seventeen (17) cell input floats on the CISS DC main bus and the payload 
power bus and provides a floor voltage to these buses during an orbiter failure. 

• Application of power to the CISS DC main bus is through a 200 amp contactor. 

• Battery 1 and 2 inputs shall be routed in separate connectors. 

• Maximum voltage drop from the battery seventeen (17) cell tap to the CISS DC 
main bus is .95V DC. 
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FIGUHE 4.4.3.2.3-1. DETAIL BLOCK DIAGRAM - DC POWER DISTRIBUTION AND CONTROL 


AC SYSTEM DESCRIPTION COMMON TO G PRIME 

• Two failure tolerance required 

• Provides reversal of phases A and B. 

• AC inputs are to be fuse protected. . , 

• Provide TLM to determine position of phase reversal relay and the amplitude of the 

AC phase voltage. 

• Each source is 400 Hz 115/200VAC RMS 

• Motor load circuit rating, 10 = .5 AMPS Maximum. 

CENTAUR G EDU THERMAL ANALYSIS STATUS ...... . hQrrr ,_, 

• Worst case hot: evaluation of EDU thermal control is through detailed thermal 

analysis. 
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- Thermal Environments: 

On-Orbit abort mission 
In-bay ZLV orbit 

- Maximum power dissipation used in detailed analysis to date is 172 watts, 
based on off-design condition of a 1500W CRU output with a 90 percent CRU 
efficiency. 

• Worst case cold: EDU thermal control maintained by internal power dissipation of 
50 watts (minimum). 


CASE 

CONTROL 
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FIGURE 4. 4.3.2. 3-2. EDU FUNCTIONAL BLOCK DIAGRAM 


4 . 4 . 3 . 2. 4 Silver Zinc Battery 

VENDOR: 

MASS: 194 1b. DIMENSIONS: 

PERFORMANCE: 

Low Voltage Tap . The output voltage shall not be less than 23.63 volts and not more than 
27.45 volts and capable of delivering steady state current of 120 amperes for 300 
milliseconds while at specified temperature range during any point of battery rated discharge. 
The item shall reach the output voltage within 10 milliseconds after application of the 120 
ampere load. 

Full Voltage Tap . The output voltage shall be between 27.0 and 32 volts and capable of 
delivering steady state currents of 80 to 120 amperes while at specified temperature range 
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during any point of battery rated discharge. The item shall reach the output voltage within 10 
milliseconds after application of any load between 80 and 120 amperes. 

Capacity . 650 ampere-hours, minimum for -1 ; 375 ampere-hours for -2. 

Open Circuit Voltage . The open circuit voltage shall not be more than 32.3 Vdc for the full 
cell tap and 27.45 Vdc for the low cell tap 24 hours after initial activation. 

ENVIRONMENTAL 

Environmental Conditions . The item shall be capable of withstanding any probable 
combination of the environmental conditions specified herein with no detrimental effects. 

Temperature 

Operating . The item shall be capable of satisfactory operation under temperature 
conditions as follows: 

a. The item shall be capable of standing in the activated condition while in a daily 
radiant temperature cycle with a lower limit of 45°F for 14 hours and an upper limit 
of 90°F for 10 hours for a period of 30 days. 

b. The item shall be capable of discharge - while in a radiant temperature between 
20°F and 120°F for a period of 6.5 hours, with heater power available and with 
loads as specified in Performance section above. 

c. The item shall be capable of standing ‘he activated condition or discharging 
while radiating to a deep space environment while mounted to a base maintained 
at 0°F, with heater power available and load as specified in Performance section 
above. 

Non-Qperatina 

Un activated . The item shall be capable of safe storage and transportation without 
impairment of its capabilities from the effects of temperature under the following 
conditions: 

a. Lower Limit - minus 65°F for periods of at least 8 hours duration. 

b. Upper Limit - plus 125°F plus the full impact of solar radiation, 360 BTU per square 
foot per hour, for periods of 4 hours per day; or plus 160°F with no solar radiation 
for periods of 4 hours per day, not to exceed 30 days. 

c. Temperature shock resulting from rapid temperature changes within the above 
limits. 

d. Continuous storage, in the unactivated condition, in temperatures between plus 
30°F and plus 45°F for a period of 5 years. 

Activated . The item shall be capable of safe storage without impairment of its 
capabilities from the effects of a storage temperature of 35°F ± 1 0°F for 30 days. 

Atmospheric Pressure. 
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Operating . The item shall be capable of operating within a cycling pressure range of 
760 mm of mercury to 1 .5 x 10- 10 mm of mercury. 

Non-Operating . The item shall be capable of withstanding pressure ranging from 
between 760 mm of mercury and 87 mm of mercury (equivalent of sea level to 50,000 
feet) in storage and transportation. 

Humidity. The item shall be capable of operating and storage at relative humidities of up to 
100 percent including condensation due to temperature change. 

Atmospheric Elements. 

Operating . The item shall be capable of operating in its installed location in any 
probable combination of the following atmospheric elements: rain, fog, smoke, wind, 
ozone, sand and dust, sunshine, and salt atmosphere. 

Explosive atmosphere . The item's heater shall operate in an explosive 
atmosphere without causing ignition of that atmosphere. 

Non-Operating . The item shall be capable of storage and transportation without 
impairing its capabilities from effects of any of the probable combinations of the 
following atmospheric elements: rain, snow, sleet, hail, ice, fog, smoke, wind, ozone, 
sunshine, sand and dust, and salt atmosphere. 

4. 4. 3. 2. 5 Lithium Thionyl Chloride Battery 

VENDOR: 

MASS: 68 lb. DIMENSIONS: 

PERFORMANCE: 

Output Power . The output voltage shall remain between 26 and 32 volts with the battery 
delivering steady state currents of 14 to 60 amperes and pulse currents of 75 amperes for not 
more than two minutes each, at least, twice during the discharge period while at specified 
temperature range during any point of battery rated discharge. The Seller shall inform the 
Buyer of all penalties, if any, resulting from the foregoing range requirements. The item shall 
reach the output voltage within 10 milliseconds maximum after application of any load 
between 14 and 60 amperes. In case of 10 milliseconds maximum criterion is not met, the 
Seller shall provide the Buyer with the minimum time required to reach the output voltage 
and any battery preconditioning procedure and the associated penalties. The procedure 
shall be reviewed and approved by the Seller. The item shall be capable of specified 
performance when operated in any combination of one(1) to three (3) batteries providing 
power when connected in parallel. 

Capacity. 250 ampere-hours minimum. 

Open Circuit Voltage . The open circuit voltage of the item shall not be less than 32.4 Vdc. 

Heater . The heater, if required, shall be designed to bring the item temperature to its 
minimum operating temperature from a minimum stabilizing temperature of plus 40F within 
10 hours. The heater shall maintain acceptable thermal control. As a design goal, the 
heater power shall be minimized and be rated at 28 Vdc. The heater shall be designed such 
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that a continuous power application, for a period of up to 90 days, will not provide a 
temperature high enough to damage the battery and/or cells. The resistance of the heater 
circuit shall be provided by the Seller. 

ENVIRONMENTAL. The item shall be capable of withstanding any probable combination of 
the environmental conditions specified herein with no detrimental effects. 

Temperature. 

Operating . The item shall be capable of satisfactory operation under any combination of the 
environments below: 

a. The item shall be capable of standing in the activated condition for a penod of 90 
days while in a conductive, convective and radiative environment ranging from 45 
to 90 degrees F. 

b. Worst Case Cold, Pre-Launch. The item shall be capable of discharge in 
accordance with Performance (above) after reaching thermal equilibrium in a 40 
degree F radiative and convective environment. 

NOTE: Convective and radiative, heat transfer shall be assumed to occur over all item 

surfaces. The average convective heat transfer coefficient will be 4 BTU/Hr ft 2 . 

Atmospheric Pressure. 

Operating . The item shall be capable of operating within a cycling pressure range of 760 mm 
of mercury to 1.5 x 10' 10 mm Hg. (The time duration for this change shall be a minimum of 5 
minutes.) 


5.0 GBT IMPLEMENTATION PLANNING 

From the beginning, it was recognized that the Ground Based Test beds capabilities would 
be tied to meeting current program system testing requirements. The GBTs role was to 
encompass vehicle simulation and testing needs from inception to the Preliminary Design 
Review (PDR). Looking at the projected vehicle developmental schedules, it was all too clear 
that the first operational GBT capabilities would have to be focused on the critical 
developmental problems. If vehicles like the Shuttle C or STV were to be supported prior to 
their PDR’s the GBT must be at least operational by August 1990. Basic avionic system 
architectural issues would have to be addressed first. The initial GBT would have to provide 
high fidelity, precision guidance & navigation simulations that supported evaluation of the 
several configurations being investigated. This dictated identification of long lead items like 
the 3-axis table. 

Software model development is another key factor in the implementation plan. Fidelity of the 
vehicle dynamic and system models is critical to establishing the GBT as a valuable program 
development resource. This usually requires actual hardware being used to develop and 
verify the fidelity of the respective software models. Availability of similar hardware often 
proves to be another pacing element. 
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Accelerating the application of new, useful technologies into current and future programs was 
another stated goal of the GBT. To this point, all the GBT capabilities were directed at 
specific problems of specific programs because of time related and money related 
constraints. The implementation plan has evolved to the point that permits visibility as to how 
this goal can be realized. First, the basic GBT hardware and software design is modular and 
thus can be changed easily to accommodate different requirements. The early phases of 
implementation require the building of a specific number of these basic modules to satisfy a 
limited number of needs. To satisfy a greater set of requirements relatively few new modules 
are required. 

Figure 5.0-1 shows an early implementation schedule and its assumptions. One of the most 
difficult problems of the implementation schedule, shown earlier in figure 1.2-2, is the amount 
of work to be done in the first phase. Between February 1989 and August 1990, over 60% of 
the total task must be accomplished. This is not consist with the relatively low front end 
funding guidelines that were provided for this study. Figure 5.0-2 shows this problem 
graphically. 


The bottom line for GBT success is being able to supply the most cost effective and useful test 
facility at the time when new programs need it the most. This implies that the projects are 
willing to pay their way and plan for such usage initially. This idealistic form of funding must 
be recognized as supplemental to basic level of funding needed to initially implement and 
later maintain GBT operations. Internal Research & Development projects are also a source 
of funding. This type of function typically accelerates the application of useful, new 
technologies and test concepts upon which later major programs are built. 


LAB PRELIMINARY IMPLEMENTATION SCHEDULE 


HLCV Related Mllestonee 
• SDV-2ES IOC 1993 
•SDV-2RS IOC 1995 
•FRWB IOC 1998-2000+ 

•PRCV IOC 1998-2000+ 

SHUTTLE C IOC 1994 

ALS IOC 1996-98 

Upper Stages 

•OTV IOC TBD 
•AOTV IOC TBD 


1 989 


1990 


1 995 



INITIAL Lab Milestones 
•Procurement 
•S/W Development 
•H/W Design A Fab 
•Fit H/W Acq 
•Facility Prep 
•Lab Activation 


LAA IOC 


Evolution 


or Downstream IOC 


Lab Program Drivers 

• 4 Year Development Cycle 

• IOC First Launch. Delivery to pad 1 year prior to Launch. 

• Full Scale Engineering Development Systems Integration Laboratory with Pathfinder Activity 

• A PC Supports Early PDRs 


FIGURE 5.0-1. IMPLEMENTATION PLAN 
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IMPLEMENTATION ISSUES 



6.0 GBT ARCHITECTURE 

This section covers both the hardware and software architectures of the GBT. It should be 
noted that the GBT has been structured to allow for a phased implementation of capabilities. 
The Target GBT is the full-up, third step configuration. It was designed to support the third 
HLCV reference configuration. This Fly Back Booster and Partially Reusable Cargo Vehicle 
must be accommodated in the Target GBT end-to-end real-time simulation. 


6.1 GBT Hardware Architecture 

Figure 6.1-1 shows the major functional hardware elements of the GBT. The following 
paragraphs will summarize each elements major functions. This will be followed by a more 
detailed discussion of each element. 
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FIGURE 6.1. 1-1. GBT TARGET CONFIGURATION 


6.1.1 GBT Core 

The GBT has been described as spanning the test continuum from pure simulation to 
hardware performance evaluation. Common to each extreme is a flexible, high through-put 
core processor. The GBT core has a main processor which is functionally divided into the 
primary processor and the avionics system simulator. The primary processor function 
includes running the simulation of the test vehicle dynamics, the mission environment and all 
other interfacing elements to the vehicle avionics system. The avionics system simulation 
function includes running the simulation of the test vehicle avionics system. This includes the 
monitor and control of all interfaces to real hardware being tested or run on the Avionics 
Hardware Test Bench. 

Selection of the processor was one of the most important and far reaching design decisions 
of the study. The unit chosen combined an excellent cost to performance ratio with a 
software and hardware migration path capable of supporting the rapidly expanding 
simulation demands of the immediate future. Initially sized with a through-put in excess of 
150 million instructions per second (MIPS), this expandable core processor has the software 
tools and I/O ports to support the GBTs current and future real-time simulation requirements. 

The four other main elements of the GBT core are the Main Control Processor, Mass Storage 
Unit, Hard Copy Processor and Interconnecting Network/Bus Structure. The Main Control 
Processor is primarily tasked with the allocation and control of GBT resources. It controls 
most of the various buses and networks running throughout the GBT and supervises use of 
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the Mass Storage and Hard Copy Processor. While functionally a part of the GBT core, the 
Main Control Processor will probably reside in the Main Control and Demonstration Center. 

The GBT Core functions and hardware specifications are described in detail in section 3.1 .2 
of the Preliminary Design Document. The GBT Core capabilities include: 

• Interfaces to tie in special test facilities to test new technologies in avionics 

- Test image processing sensors 

- Test inertial units 

- Test actuators 

- Test fluids/pneumatics 

• Support complete vehicle analog and discrete interfaces in core testbed. 

• Processing capacity to simulate vehicle dynamics, environment, and all avionics 
models. 

• Hardware to support test setup, monitor and control from a central location 

• Instrumentation processing to support all instrumentation interfaces. 

• Mass storage capable of storing system software and data, and continuous storage 
of test data 

• Hardware to support off-line software development, post processing or 
demonstration. 

6. 1.1.1 Main Processor 

The GBT Main Processor primarily was designed and sized to handle a high fidelity real time 
simulation of the airborne systems, vehicle dynamics and flight environment of the most 
complex HLCV reference vehicle. Basic to its design is the ability to integrate system or 
subsystem level testing of real hardware into an end-to-end simulation so the performance of 
the hardware could be evaluated in its intended functional environment. Figures 6.1. 1.1-1 
and 6. 1.1. 1-2 show open loop hardware testing and closed loop hardware testing using the 
Main Processor. 

The Main Processor must also be able to integrate other testing resources into the end to end 
simulations to increase the fidelity of the tests. The Guidance & Navigation Labs 3-axis table, 
as an example, allows more complete testing of vehicle inertial elements or complete 
guidance and control systems. The Main Processor would integrate the 3-axis table 
movements with the simulation time line events. 



FIGURE 6.1. 1.1-1. OPEN LOOP AVIONICS TESTING IN CORE FACILITY 
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FIGURE 6.1. 1.1-2. CLOSED LOOP AVIONICS TESTING IN CORE FACILITY 


Core processing throughput sizing is shown in figure 6. 1.1. 1-3. The estimate of processor 
power and speed was made by extrapolation from a current simulation. A second method 
(see figure 6.1. 1.1-4) based upon sensor input and other system operational parameters 
came up with a slightly higher figure. An analysis of the scope and nature of the simulation 
required to yield an end to end, real time simulation of the FRWB and PRCV indicated a 
minimum rating for the primary processor should be 150 MIPS. Product design practice 
would require a modular architecture in which the processor could be scaled up to meet the 
job. 


REQUIREMENT: 150 MIPS - FOR REAL TIME SIMULATION OF HLCV ERA VEHICLES 

BASIS: EXTRAPOLATION FROM CURRENT SIMULATION 

• 6 DOF FLIGHT TRAJECTORY SIMULATION 

• 96 STATE VARIABLES 

• 20 MILLISECOND AUTOPILOT CYCLE 

• XI 0-20 INTERCYCLE 

• 2 NASTRAN MODES, BENDING MODE 

• AUTOPILOT FUNCTIONS, BENDING MODES, DISTRIBUTED AERODYNAMICS, MASS 
DISTRIBUTION UPDATING 

• APOLLO 3000 WORKSTATION RUNS NON-REAL TIME SIMULATION IN 10 HOURS. REAL 
TIME: 270 SECONDS (REAL TIME SPEED UP: 133X FOR IDENTICAL TASK) 

• INCREASED SCOPE OF SIMULATION 

• ADD 4 RATE GYROS 

• DISTRIBUTED ACCELEROMETERS 

• AIR DATA SENSORS 

• X5 PROPULSION SYSTEM INTERFACE 

• ADAPTIVE GUIDANCE 

• AUTOLAND 

♦ INCREASE FOR GROWTH 


FIGURE 6.1. 1.1-3. CORE PROCESSOR THROUGH-PUT SIZING USING EXTRAPOLATION 


Page 60 


9/25/89, 11:40 AM 









Final Report, Volume 2 


Definition ofAvionics Concepts foraHeavy Lift Cargo Vehicle 


MODULE 

INSTRUCTIONS 
PER LOOP 

COMP 
RATE (HZ) 

INSTRUCTION 
PER SEC/LOOP 

LOOP 

INSTRUCTIONS 
PER SEC 

RCS 

124 

500 

62K 

20 

1.24M 

ENGINE (THRUST) 

114 

500-1 OK 

57K-1.14M 

20 

1 . 14M-22.8M 

(FUEL USE) 

27 

500 

13.5K 

20 

270K 

GRAVITY 

572 

500 

286K 

1 

286K 

GRAVITY GRADIENT 

181 

500 

90.5K 

1 

91 K 

VEH DYNAMICS 

1481 

500-1 OK 

740.5K-14.8M 

1 

741 K-14.8M 

ATMOSPHERE 

52 

10-500 

520-26K 

1 

26K 

AERO FORCES 

663 

500 

331. 5K 

1 

332K 

MASS PROPS (TANKS) 

63 

10-500 

630-31. 5K 

20 

1 3K-630K 

(VEHICLE) 

157 

10-500 

1570-78. 5K 

23 

1 1 K-550K 

FUEL SLOSH 

400 

500 

200K 

1 

200K 

BODY BENDING 

1000 

500 

500K 

1 

500K 

TOTAL W/O ACTUATOR AND I/O 





4.9M-41 .7 

I/O 

50 

500 

25 K 

500 

12.5M 

ACTUATORS 

399 

10000* 

4M 

40 

1 60M 

TOTAL 





1 17.4M-214.2M 

1 NOTE: HIGHER COMPUTATION RATES ARE FOR HIGH FIDELITY EVENTS SUCH AS VEHICLE SEPARATION. 1 


FIGURE 6.1. 1.1-4. CORE PROCESSOR THROUGHPUT SIZING USING SPECIFIC SYSTEM DESIGN 
(SINGLE VEHICLE, MEDIUM FIDELITY, 3-STRING AUTOPILOT AVIONICS ON HOT BENCH) 


Figure 6. 1.1. 1-5 shows the basic architecture of this expandable parallel processor. Eight 
RISC processor sets will be connected to the backplane bus whose current, Phase I rating is 
64 million bytes per second (MB/sec). The RISC processors are rated at +20 MIPS each. An 
internal global memory is also connected to the MC bus (backplane bus). Input/output flows 
from the backplane bus through a VME I/O module in the Phase 1 configuration. Each of 
these VME buses currently are rated at +26 MBS average. The number and performance of 
the VME buses will be increased in subsequent phases. The main processor design easily 
accommodates upgrades to backplane global memory processor and I/O modules. 
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6. 1.1. 2 Main Control Processor (MCP) 

The main control processor, though functionally part of the GBT core, will probably be in the 
Main Control and Demonstration Center. Designed to control and monitor overall GBT 
operations, this parallel processor shares the open architecture and highly compatible 
features of the main processor. Figure 6.1. 1.2-1 shows the Control Processor initial, Phase 1 
configuration. Four 25 MHz, 68030 CPU's are teamed with four 68882 floating point co- 
processors to provide the necessary processing power to control the Phase 1 GBT. A 16 Mb 
RAM provides the initial "fast memory" necessary to support Phase 1 processing levels. The 
RAM is expandable to 120 Mb and is connected to the backplane "memory" bus. 

Control and display functions are accommodated by the MCP's independent graphics 
subsystem. It supports a 19" high resolution monitor for high quality color graphic displays. 
Keyboard and mouse inputs are provided. Storage and retrieval of data are provided by disk 
and tape controllers. 

Input/output is a key function of the MCP. Two independent VME bus systems are provided. 
Interface modules provide access to the GBT ProNet 80, 1553 and orbiter buses/networks. A 
separate multibus interface accommodates the GBT Ethernet. 
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6. 1.1. 3 Mass Storage 

The GBT Phase 1 Mass Storage includes a 1 GByte 8" hard disk system, 2-1/2" SCSI tape 
units and a 1/4" 150 MB 5.25 cartridge backup tape unit. These three types of storage units 
were selected for specific functions. The 8" hard disk provides rapid access to currently 
required programs and data. The tape provides storage for more periodic data retrieval and 
storage where access time is not important. The quarter inch cartridge tape is used for data 
backup as well as being a convenient and popular medium for introducing new software into 
the system. 

6.1.2 Main Control and Demonstration Center 

Within this element rests the primary control and allocation of all the GBT resources. Central 
to its function is the Main Control Processor that is linked to all the available resources by an 
extensive inter / intra lab communications network. The Main Control Center and 
Demonstration Center are collocated because of their complementary functions. The 
Demonstration monitors may be used to supplement the status displays available to the 
core’s Main Control Processor. The graphics processors will also supplement the Main 
Control Processor in controlling parallel operations going on within the GBT. 

The Demonstration Center primarily consists of four graphics processors driving four large 
screen monitors. The graphics processors are used to develop display and other support 
type graphics. Working with the large screen monitors, the processors can reproduce 
demonstration graphics depicting anything from real-time test parameters to reproduction of 
demonstration graphics. Figure 6. 1.2-1 shows one conceptual layout of the Main Control and 
Demonstration Center. 
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6. 1.2.1 Main Control Processor (MCP) 

This unit was discussed previously in connection with its control functions centered about the 
GBT Core. The MCP plays a key role in the control and monitoring function of the Main 
Control and Demonstration Center. During demonstrations the MCP can be used to 
coordinate the multimedia presentations. Live and pre-stored material can be routed to the 
large presentation monitors, combining real time test demonstrations with the necessary 
introductory and reference information. During demonstrations, the MCP is used to set up the 
data paths from the GBT resources to the Graphics Processors in the Demonstration Center 
via the communications and control buses. Data from the Mass Storage, Video Recorders, 
and the Instrumentation Resource Lab can be accessed and/or routed over the High 
Speed/DMA and other GBT buses. 

6. 1.2. 2 Graphics Processors 

The four graphics processors are intended to perform several functions. Basically, they must 
be able to process raw data into pre-determined graphic displays. They can be able to 
develop the graphics software to facilitate this processing. The graphics processors must 
also be able to support two different graphic outputs and have limited video processing 
capabilities. 

During demonstrations and integrated GBT operations, the graphics processors can be used 
as auxiliary control terminals or display units. Data routed from the MCP can be displayed on 
the Graphic Processor screen or routed to the demonstration monitors. MCP control can be 
supplemented by the graphic processor when properly configured by the MCP. 

The Graphic Processors are designed to develop the graphic displays used for lab control 
monitoring and for demonstrations. In this role the graphic processor can operate 
independently or tie in the necessary resources to test the function of the graphic software 
being developed. The communications and control bus will be used to handle this function. 

The graphics processors will, in later phases, be able to do a limited amount of video 
processing. This processing will permit the combining of pre-recorded video from a VCR with 
computer generated graphics. This "GenLoc" function will permit the easy production of 
video presentations of GBT test results viewable via any standard VCR. 

6. 1.2. 3 Demonstration Monitors 

Figure 6.1. 2-1 shows a conceptual layout of a Main Control and Demonstration Center in 
which the large demonstration monitors are pictured. The GBT Target Configuration calls for 
four of these large, 44" minimum, color monitors. These units must be able to accommodate 
standard color TV composite, RGB, and the "multi-sync" outputs from the graphic processors. 

6. 1.2. 4 Hard Copy Processors 

These units will initially be laser and standard dot matrix printers used to support the 
development of GBT software and graphics. In later phases, scanners and color printers will 
be added to support the demonstration function. 

6. 1.2. 5 Graphics/Video Processors and Storage Units 
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Initial graphics and video processing will be restricted to standard video cartridge recorders 
capable of editing and recording standard broadcast video and the composite output from the 
graphics processors. If GBT demonstrations require production of more elaborate 
presentations, commercial, broadcast quality video processing equipment may be 
considered to preserve the quality of the finished video presentations. 

6.1.3 Avionics Hardware Test Bench 

The Avionics Hardware Test Bed is the third major segment of the GBT Target Configuration. 

It contains the interfacing units, busses and harnesses necessary to accommodate the GBT 
Benchmark hardware. The benchmark hardware is a collection of current avionics units 
which, when connected to the required interfacing harness, comprise a fully functional 
avionics system.lt provides a real world performance standard to which the candidate 
hardware can be compared. The Avionics Hardware Test Bed therefor facilitates 
development and evaluation of new avionics systems, and components by providing a high 
fidelity, native environment in which they can be tested. 

6. 1.3.1 Hotbench 

The GBT Hotbench is designed and configured to include hook-up with a unique LRU box. 
Benchmark tests can be performed to compare system operation or box to box operation. 
Boxes may be compared to software models. The hotbench is programmable via 
programmable digital to analog and analog to digital converters. Unique harness and cable 
will need to be furnished or built to plug-in unique boxes. Hotbench support software wil 
permit tailoring of signal characteristics by adjusting skew and delay of the interfacing 
signals. 

The Phase 1 hotbench design will have all the harness and cabling to facilitate Shuttle-C 
(Option C) hardware. Cable style, length and impedance shall be as close to actual as 
required or possible. When unique or option C hardware is not available software simulation 
may be run to emulate that hardware. The general path to the vehicle bus is via 
programmable A/D and D/A converters. Discretes in many cases will be shared between 
either hardwire or other remote voter units (RVU). 

6.1.4 Instrumentation 

The Instrumentation segment is a subset of the Avionics hardware test bed that permits local 
control and monitoring of the test bed hardware or units under test. It functionally duplicities 
an instrumentation ground station and is equipped to analyze vehicle bus traffic. 

6.1.5 Guidance & Navigation Lab 

The GBT G&N area of the lab will contain a dedicated 3-axis table with a thermal chamber. 
The INU will be mounted and used for closed loop system evaluation and system operation. 
The LRU 1553 outputs and discretes pass through table slip ring connectors and are put onto 
the vehicle bus. Unit accelerations will be simulated via software. For three string 
configurations, two other strings will be simulated to allow operation and testing of such 
functions as fault isolation redundancy management and system functions checkout. 

Hardware will be completely simulated as well. Benchmark testing will be available with the 
G&N section of the lab. Box to box comparisons may be made open loop or in an overall 
closed loop system performance mode. During open loop test the local local processor will 
be able to do ATP type test as well as check both the navigation and flight control section of 
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the INU. Data collection will be available locally to evaluate LRU during ATP and envelope 
tests. 

6.1.6 Software Development Facility 

A major design driver is the architecture of the user friendly software that yielded the efficient 
and highly compatible interface for potential users. The cost effectiveness of GBT usage 
rests squarely on its accessibility and its ability to accommodate several tasks in parallel. 

This translates to a modular set of software tools, tailorable to specific applications and 
executed with data that bounds the required performance regimes. The tailoring and 
selection of appropriate performance data is accomplished by a menu driven linkage 
process.The Software Development Facility will initially be located in the Main Control and 
Demonstration Facility while the basic GBT operational and benchmark software is being 
integrated. As the GBT phases into operation, the function of this element will shift to the 
primary user interface. It will become the site where users will assemble the modularized 
software tools and simulations into the desired testing regimes. The Software Development 
Facility will also host the building of the demonstration graphics. 

6.1.7 Power Systems Extension 

This GBT extension will be capable of testing new technologies in Power Systems 
components and architectures. This Phase 2 extension will support not only the normal 
evaluation of candidate power system sources and architectures, but will be focused on EMA 
power supply development and testing. 

6.1.8 Navigation Aid and Image Processing Extension 

This GBT extension is scheduled for Phase 2 implementation. It is designed to provide 
developmental support as well as verification of autonomous rendezvous and docking aids in 
the near term and to support the development of approach and landing systems for the far 
term Flyback Booster. 


AUTONOMOUS ATTITUDE AND POSITION SENSORS 

• CCD, SCANNING LASER, GPS, STAR TRACKER/REFLECTOR, HORIZON SENSOR 

• APPLICATION: ENABLES RENDEZVOUS AND DOCKING, AUTOLAND 

- BENEFITS: OPERATIONAL FLEXIBILITY, AUTONOMY, SAFETY 

• LAB SUPPORT REQUIREMENTS: 

- 3-AXIS TABLE 

- FLAT FLOOR 

- HIGH DEFINITION IMAGING SYSTEM 

- STAR TRACKER 

- GPS AIRBORNE AND SYSTEM EMULATORS 

• OVERALL LAB BENEFITS 

- CAN DEMONSTRATE AVON ICS SUBSYSTEMS AND OPERATIONS FOR 

- RENDEZVOUS AND DOCKING 

- APPROACH 

- LANDING 

• AUTOLAND 

- DEMO FAILURE TOLERANCE, OVERRIDE CAPABILITIES 

- DEVELOP OPERATIONAL REQUIREMENTS, PROXIMITY OPERATIONS 

- DEFINE AVIONICS REQUIREMENTS 


FIGURE 6.1 .8-1. IMAGE PROCESSING/NAV AID EXTENSION SUMMARY 
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Two, Phase 2 functions were detailed within the HLCV 2nd Quarterly review, September 
1988. They are: (a) a moving scene generator, and (b) precision stellar star generator. 

6. 1.8.1 Scene Generation 

The moving Scene Generator would work together with the existing six DOF flat floor. A 
camera would be mounted and fly into a moving scene. Image recognition and image 
manipulation would be possible. Surface could be changed rapidly. Figure 6.1. 8.1-1 shows 
the scene generator can be used with both the flat floor and the G&N Lab. 
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FIGURE 6.1. 8.1-1. RENDEZVOUS AND DOCKING/TERMINAL LAND DEMO 


6. 1.8. 2 Stellar Projection 

The G&N will be outfitted with a dark room enclosure for projection and an open ceiling to 
view actual stars. A combination of both fixed and slow moving scenes, such as a Space 
Station docking port, will allow evaluation and test integration of items such as Position/ 
velocity updates; Terminal navigation; Image recognition; Docking/rendezvous; and Re-entry. 
These are shown in Figure 6. 1.8. 2-1. 
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OBJECTIVE: To provide a means of verifying and demonstrating end-to-end attitude 
update using an external starfield. 


ATTITUDE 


OPEN CEILING (REAL STARS) 

► LIMITED STARFI ELD/STAR SCANNER 
* STELLAR SIMULATION 

TOTAL SOFTWARE SIMULATION 


a LEVEL 
° F 

▼FIDELITY 


RATIONALE: Limited starfield/star scanner and stellar updates are not expen- 

sive and will benefit the lab for test integration and demonstration 
purposes. Hardware emulation of star scanner/tracker equipment 
is expensive, and a modified Sony CCD camera will be evaluated 
in its place. 

APPROACH: A starfield and stellar update capability may be configured initially 

and mounted on the 3-axis table via an adapter plate and a 
blackout structure. 


BENEFITS: (1) No mods to stellar update software 

(2) External Star Simulators provide variable star magnitudes. 


FIGURE 6.1. 8.2-1. LIMITED STARFIELD / STAR SCANNER 


6.2 Phase 1 Configuration 

The initial Phase 1 GBT configuration is scheduled to be operable in August of 1990. Figure 
6.2-1 lists several of the support capabilities to be demonstrated at that time. SDV-2ES is the 
first HLCV reference vehicle and functionally equivalent to Shuttle-C. Its mission profile is 
depicted in figure 6.2-2. Four software mission phase models are required for the Phase 1 
IOC. They include Launch, Ascent, Orbital maneuvering and a ballistic type of controlled 
entry. 

Benchmark hardware includes the equivalent of 1 string of the Shuttle-Derived Vehicle 
avionics system. Limited interface capabilities on the Avionics hardware testbed can accom- 
modate only two "boxes". (This capability will be expanded substantially during Phase 2). 

Figure 6.2-3 shows a vehicle processing throughput as a function of time. These projected 
through-put levels added to the requirements for vehicle dynamics and mission environment 
require the core processor to equal or exceed its projected 70+ MIPS configuration for Phase 
1 . 

Flight operations for Shuttle-C, shown in figure 6.2-4 were used in projecting the throughput 
requirements. 

The Phase 1 GBT Configuration is pictured in figure 6.2-5. Many target capabilities are 
absent. Among these are the interface provisions to many of the resource labs and 
extensions. The G&N Lab is the exception where a full link is present. The Propulsion Lab 
also will have a port available on the fiber optic communications and control bus. 
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1 . MISSION MODELS * (2DV-2ES) 

• LAUNCH 

• ASCENT 

• ON ORBIT (MANEUVER) 

• ENTRY 

2. SYSTEM TEST 

• SDV REFERENCE SYSTEM 

• IMU 

• COMPUTER 

• DAS 

• MDU 

• RDU 

• MDM * INTERFACE ONLY 

• EIU * INTERFACE ONLY 

3. OUTSIDE RESOURCES 

• SSME LAB INTERFACE 

• EMA (OPTION) 


FIGURE 6.2-1. PHASE 1 CAPABILITIES AND CONSTRAINTS 



FIGURE 6.2-2. MISSION PROFILE 
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INCLUDES HEALTH MONITORING. 
INCLUDES REDUNDANCY WHERE KNOWN. 
NO MARGIN ALLOWANCE. 



PROPULSION 
(INCLUDES ENGINE 
OUT CAPABILITY) 


I wIvIvA, 

■ WjAJAJt * ************* ♦ 



LRB 

SEPARATION 


PAYLOAO 

SEPARATION 


END OF 
MISSION 


FIGURE 6.2-3. PHASE 1 VEHICLE PROCESSING TIMELINE 


• AUTONOMOUS FLIGHT CONTROL TO ORBITAL INSERTION, CIRCULIZATION AND 
DEORBIT 

- SIMPLEX SHUTTLE-C MISSION CONTROL CENTER 

- BASIC SHUTTLE-C AVIONICS FOR THIS FUNCTION 

- PRECURSOR MISSION PLANNING (SIMPLEX), PAYLOAD INTEGRATION TO CARGO BAY 
BY SHUTTLE-C 

• ORBITAL DEPLOY MISSIONS (E.G., PLANETARY AND OTHER FREE FLYING 
SPACECRAFT 

- PAYLOAD DEVELOPER RESPONSIBLE FOR OPERATIONS FROM POCC AFTER PAYLOAD 
SEPARATION 

• SPACE STATION MISSIONS 

- PRECURSOR MISSION (A ON ORBIT) PLANNING DONE AS PART OF OMV/SS ACTIVITY 

- OMV/SPACE STATION CONTROL CENTER RESPONSIBLE FOR RENDEZVOUS, PROX- 
OPS, DOCKING, MISSION OPERATIONS (E.G., ASSEMBLY) AND DEORBIT FROM 
SS/OMV CONTROL CENTER OR MULTI-PURPOSE CONTROL CENTER 

- VERY LIMITED "KIT ON" SHUTTLE-C DELTA AVIONICS INCLUDING BATTERIES, ETC. 


FIGURE 6.2-4. FLIGHT OPERATIONS 
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The GBT Core Processor is only partially filled, giving it a throughput of about 70+ MIPS. The 
software will be developed initially on the Graphic Processors residing in the display center. 
The function of the display/demo center and software development will be performed at that 
location. The benchmark hardware used in the avionics hardware testbed will probably be a 
single string of the Shuttle-C architecture. The interfacing capabilities of the Master I/O unit 
will accommodate only the equivalent of an Inertial Navigation Unit (INU) and a Remote 
Voting Unit (RVU) simultaneously. 


6.3 Phase 2 Configuration 

The Phase 2 GBT capabilities and constraints are listed in figure 6.3-1 . Vehicle simulation 
capabilities now include the ALS Booster and Core. The overall simulation capability is more 
generic than before, with the complete range of software modules completed. The Core 
Processor has been fully expanded to the target configuration, permitting complete end-to- 
end, real-time simulations. Rendezvous and Docking and Precision Entry simulations will 
also be possible in Phase 2. 

Hardware testing of a complete "string" of avionics equipment will be possible with the 
avionics hardware test bench. A more complete set of generic software models will be 
available for use. 
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Figure 6.3-2 depicts the Phase 2 GBT configuration. Note the changes in the hardware test 
bed and display center. Now a separate software development facility is available and links 
are available to a variety of labs and extensions. 


MISSION MODELS - SHUTTLE-C, ALS, (GENERIC) 

• LAUNCH 

• ASCENT 

• ON ORBIT (STV) MANEUVER, RENDEZVOUS & DOCKING 

• ENTRY (CONTROLLED AND PRECISION) 


SYSTEM TEST ■ SHUTTLE-C, ALS, STV (GENERIC) 

• G/NS 

• F/CS 

• F/CP 

• DAS 

• PC 

• S/SC 


OUTSIDE RESOURCES 

• SSME LAB INTERFACE 

• ACTUATOR LAB 


ORIGINAL PAGE IS 
OF POOR QUALITY 


FIGURE 6.3-1. PHASE II CAPABILITIES/CONSTRAINTS 



FIGURE 6.3-2. GBT PHASE II CONFIGURATION 
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6.4. GBT Software Architecture 

6.4.1 Software Architecture Characteristics 

6. 4. 1.1 Real-time Simulations Multi-Processor Based 

The software supports real-time, multi-processor based simulations of existing or new 
unmanned vehicles including Shuttle-C, Centaur, OMV, STV, and ALS. The software is 
structured to take advantage of the multi -processor host computer to meet the simulation 
speed requirements. Additionally, the software is structured to allow variable frame-times for 
the individual software modules. An example of the multi-processor, variable frame time 
structure is shown in figure 6.4. 1.1-1. 

6. 4. 1.2 Phases of Flight 

The software is structured to allow the capability to simulate any phase of flight including pre- 
launch, ascent, on-orbit, re-entry and landing. This capability allows the simulation of both 
individual flight phases and an integrated mission consisting of multiple flight phases. 


Instructions per frame 


Processor 

#1 


Processor 

#2 


Processor 

#3 


Processor 

#40 


Input 

1501 

Act 1 
(400) 

Eng 1 
(141) 

Vehicle 

Dynamics 

(1481) 

Act 1 
(400) 

Eng 1 
(141) 

Vehicle 

Dynamics 

(1481) 


LZ 1 



Atmosphere 
Gravity 
GravGrad 
Aero (1468; 

Input 

1501 

Act 2 
(400) 


ACS 1-10 
(1240) 

Act 2 
(400) 



L_ 1 



Input 

1501 

Act 3 
(400) 

Eng 2 
(141) 

ACS 10-20 
(1240) 

Act 3 
(400) 

Eng 2 
(141) 

ACS 10-20 
(1240) 


• 

• 

• 





Input 

1501 

Act 40 
(400) 



Act 40 
(400) 



2 msec (500 Hz) 1 


Act 1 I Eng t 
(400) I (141) 


Act 2 
(400) 


Vehicle 

Dynamics 


Mass Proos 
10-15 
( 1100 ) 


Act 3 
(400) 


Eng 2 
(141) 


Body 

Bending 

( 1000 ) 


Act 40 
(400) 


* Fastest processing requirements in processor #1 

- 41215 instructions / 2 msec => 20.6 MIPS 

* Other processor requirements 

- Actuator and engines computations 

- 11595 instructions / 2 msec => 5.8 MIPS / processor 

* Low frequency computations (atmosphere, gravity, etc.) 

- Performed in any available time "slots" 


Output 

(625) 


Output 

(625) 


Output 

(625) 


Output 

(625) 


FIGURE 6.4.1. 1-1. TYPICAL PARALLEL-PROCESSING TIMING DIAGRAM (SINGLE VEHICLE, 
MEDIUM FIDELITY, 3-STRING AUTOPILOT AVIONICS) 


6. 4. 1.3 Integration of Avionics Hardware Into Real-Time Simulations 

The software provides interface routines to drive appropriate I/O hardware. These routines 
and associated I/O hardware have the capability of reading from and writing to existing 
and/or new avionics hardware in a real-time manner. The avionics hardware to be supported 
includes Guidance and Navigation systems, Controls interface, data acquisition system and 
power systems. 
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6. 4. 1.4 Real Time Simulation of Avionics Hardware 

The software modules perform real-time and non-real-time simulations of existing or new 
avionics hardware. These modules are in varying levels of fidelity to meet necessary real- 
time requirements. The software allows the simulation of multi-string avionics hardware by 
the use of multiple software modules and/or actual hardware. 

6. 4. 1.5 Fault Insertion Capabilities 

The software allows for the simulation of vehicle/subsystem faults and avionics hardware 
faults. Manual, pre-canned and random fault-insertion capabilities are provided. 

6. 4. 1.6 Stand-Alone Avionics Hardware Testing 

The software provides the capability to perform stand-alone testing of existing and/or new 
avionic hardware. This capability is independent of the main simulation, though individual 
simulation routines are used when necessary. The stand-alone testing has an acceptance 
test procedure (ATP) type of format, providing stimuli to the hardware and monitoring 
appropriate hardware responses. The software is structured to allow for a variety of test 
lengths and includes automatic, semi-automatic and manual test capabilities. The semi- 
automatic and manual test modes are such that an operator can manually select which 
hardware inputs to stimulate and which hardware outputs to monitor. Additionally, the 
operator may manually start the execution of any pre-programmed automatic test sequences. 

6. 4. 1.7 User Friendly Interface 

The software provides a user-friendly interface based on a tree-structure and utilizing 
multiple window displays. 

6. 4. 1.8 Multiple Users 

The software provides multiple user capability. This capability allows separate users to 
perform simultaneous independent simulations, LRV tests and software development within 
the performance constraints of the host computer, bus traffic and I/O constraints and avionics 
hardware availability. 

6.4.2 Specific Simulations Provided for Phase 1 

The following specific, full-up simulators shall be provided: 

- Shuttle-C trajectory simulation 

- Shuttle-C engine simulation 

- Electromechanical actuator simulation 

- Others TBD 

6.4.3 Lab Configuration Software 
6.4.3. 1 Program Status 

The lab configuration software maintains a consistent structure during the development of the 
lab. The structure allows for a flexible simulation development and execution environment. 
This structure is be based on the use of generic simulation modules and application-specific 
data files. 
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6. 4. 3. 2 Tree-Based Multi-Level Menus 

The lab configuration software shall incorporate the tree-structured elements shown in Figure 
6.4.3.2-1, -2 and -3. 



FIGURE 6.4.3.2-1. LAB CONFIGURATION SOFTWARE: GBT TARGET AND PHASE 1 

DESIGNS - PROGRAM / MENU STRUCTURE 
NOTE: EACH BLOCK REPRESENTS AN INDIVIDUAL MAIN PROGRAM MODULE AND MENU 



FIGURE 6.4.3.2-2. LAB CONFIGURATION SOFTWARE: GBT TARGET AND PHASE 1 
DESIGNS - PROGRAM / MENU STRUCTURE (CONT) 

NOTE: EACH BLOCK REPRESENTS AN INDIVIDUAL MAIN PROGRAM MODULE AND MENU 
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FIGURE 6.4. 3.2-3. LAB CONFIGURATION SOFTWARE: GBT TARGET AND PHASE 1 
DESIGNS - PROGRAM / MENU STRUCTURE (CONT) 

NOTE: EACH BLOCK REPRESENTS AN INDIVIDUAL MAIN PROGRAM MODULE AND MENU 


6. 4. 3. 3 Elements 

All program modules and menus are generic, i.e., the menu structure changes for different 
simulations and lab configurations. All elements are data driven either by user defined data 
files and/or user commands from the keyboard. The software design goal is to not require 
new software modules to be written (coded) as a new simulation is defined. 

6.4.4 Simulation Models 

6.4.4. 1 Mission/Vehicle/Environment Models 

Simulation software is provided to support avionics testing in simulated ascent, orbital and 
controlled reentry phases. The fidelities and frame types of the software modules are 
variable and selectable using data files. As a minimum, software modules are provided to 
support components shown in figure 6.4.4. 1-1. 


SIMULATION MODULE DESCRIPTIONS 

• 6 DOF DYNAMICS - PROPAGATES 6 DOF DYNAMICS FOR EACH VEHICLE 

• MASS PROPERTIES - CALCULATES TIME VARYING VEHICLE MASS PROPERTIES BASED ON FUEL 
CONSUMPTION AND VEHICLE STAGING / SEPARATION EVENTS 

• AERODYNAMICS - CALCULATES AERODYNAMIC FORCES USING LOWER AND UPPER ATMOSPHERES AND 
REENTRY MODELS 

• BODY BENDING - CALCULATES VEHICLE BENDING EFFECTS BASED ON VEHICLE STIFFNESS AND/OR 
BENDING MODES 

• SLOSH - CALCU LATES FUEL SLOSH EFFECTS ON VEH ICLE ACCELERATIONS AND CG 

• MAIN ENGINES - CALCULATES ENGINE THRUST AND FUEL USE BASED ON LOW AND HIGH FIDELITY ENGINE 
MODELS 

• REACTION CONTROL SYSTEM (RCS) - CALCULATES RCS EFFECTS AND FUEL USE BASED ON LOW AND HIGH 
FIDELITY RCS AND RCS FLUIDS MODELS 

• ACTUATORS - CALCULATES ACTUATOR POSITIONS BASED ON LOW AND HIGH FIDELITY ELECTRO- 
MECHANICAL ACTUATOR MODELS 

• THRUST VECTOR CONTROL (TVC) - CALCULATES THRUST VECTOR FORCES BASED ON ENGINE THRUST, 
ACTUATOR POSITIONS, AND VEHICLE BENDING EFFECTS 

• ENVIRONMENT - CALCULATES ATMOSPHERIC PARAMETERS BASED ON ALTITUDE, SIMULATES 
DISTURBANCES AND WIND EFFECTS 

• HARDWARE / SOFTWARE INTERFACES - PROVIDES I/O ROUTINES FOR HARDWARE IN THE LOOP, I/O 
SIMULATIONS FOR SIMULATED HARDWARE 
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FIGURE 6. 4. 4.1-1. PHASE 1 SIMULATION MODELS: - MISSION/VEHICLE/ENVIRONMENT 

MODELS 


6. 4. 4. 2 Avionics Simulation Models 

Simulation software is provided to functionally simulate avionics hardware. The software 
models are structured to allow for the testing of redundancy concepts such as multiple sets of 
avionics (hardware and/or software simulation), cross-channel communications, 
synchronization and shielding. Software modules are provided to support the components 
shown in figure 6. 4. 4. 2-1. 


DESCRIPTIONS 

• NAVIGATION - SIMULATES INERTIAL SENSORS AND FLIGHT CONTROL PROCESSOR FUNCTIONALITY AND 
INTERFACE ELECTRONICS 

• VOTING LOGIC - SIMULATES VOTING LOGIC FUNCTIONALITY AND INTERFACE ELECTRONICS 

• DATA ACQUISITION - SIMULATES DATA ACQUISITION, REDUCTION AND TRANSMISSION AND INTERFACE 
ELECTRONICS 

• ENGINE CONTROLLER - SIMULATES ENGINE CONTROLLER FUNCTIONALITY AND INTERFACE ELECTRONICS 

• RGU AND AA - SIMULATES RATE GYROS AND ACCELEROMETERS 

• CROSS-CHANNEL COMMUNICATIONS - PROVIDES CROSS-CHANNEL DATA LINK BETWEEN AVIONICS 
MODULES (HARDWARE AND/OR SOFTWARE MODELS) 

• SYNCHRONIZATION AND SKEWING - SYNCHRONIZES WITH HARDWARE AND PROVIDES ARTIFICIAL SKEWING 
TO SOFTWARE MODELS 

• INSTRUMENTATION - SIMULATES DATA NECESSARY FOR DAS OPERATION 


FIGURE 6.4. 4. 2-1 . PHASE 1 SIMULATION MODELS: - AVIONICS SIMULATOR MODELS 


7.0 HLCV GROUND BASED TESTBED FACILITIES 

The detailed facility requirements for each major GBT element are contained in the 
Preliminary Design Document, (PDD). These requirements cover the basic power, space 
and environmental needs of the major GBT elements but don't address the overall Lab 
layout. This section will summarize the recommendations from which the layout will be 
determined. Fuller definition of the layout was deferred pending definition of the actual GBT 
site and the modification possible with the funds allotted. 


7.1 Location 

Key to the utility of the Ground Based Testbed is its proximity to the resources it must draw 
upon and serve. Early utilization will be enhanced if it is close to existing testing facilities. As 
the GBT primary processor and attendant communication networks are brought onto line, 
closed loop simulations, involving one or more adjacent labs will become possible. Early 
attention to those existing laboratory resources that would most befit from the added GBT 
capabilities should be a factor in selecting the GBT location. 
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A second factor involves the GBTs potential to become an effective and convenient 
demonstration facility. This potential will obviously be enhanced if the GBT is in close 
proximity to the existing conference and administrative sites. Figure 7.1-1 shows the 
candidate GBT site and the adjacent test and administrative facilities. 


7.2 GBT Layout 

Figure 7.2-1 shows the basic Building 4476 1st floor plan. The area designated for the GBT 
is shown in figure 7.2-2. 

A change to this area is already in work, but the completion dates do not support the current 
Phase 1 IOC date of August 1990. This proposed change has three options. The "A" option 
was used in this study. 

A general GBT layout is shown in Figure 7.2-3. Detailed layouts of existing labs at GDSS 
were used as a basis for this preliminary plan. Volume II contains these layouts and a list of 
the "lessons learned" during their implementation and use. 



FIGURE 7.1-1.. GBT FACILITY LOCATION 
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FIGURE 7.2-1. BUILDING 4476, MSFC 



Page 79 


9/25/89, 11:40 AM 
















Final Report, Volume 2 


Definition of Avionics Concepts for a Heavy Lift Cargo Vehicle 


TABLE 2.2.2-1 


NO DESCRIPTION 

RATIONALE 

1 Southern High Bay Extension with 2 large 
access doors. 

2 Northern G&N Lab Extension 

3 Northern High Bay Extension 

4 Mezzanine Modification 

1 . Provides access to High Bay and staging areas #1 & #2 

2. Accommodates G&N labs & provides North Star LOS. 
Provides easiest method to provide isolation pads for 3 
axis table. 

3. Accommodates future "flow through" processing of 
modules & staging. 

4 . Optimizes main processor areas to resources 
(shortens distance to Hot Bench & staging areas by 
placing main processor on mezzanine.) 


7.2.3 Proposed GBT Space Allocations 

The original Target GBT floor plan approached 10000 square feet and featured a two story 
layout. The candidate site offered about one third of the space unmodified. Optional add-ons 
bring the usable space to around 5000 square feet and optimizes the usefulness of the 2nd 
floor area. 

7. 2. 3.1 Demonstration, Control and Processing Centers 

Figure 7.2.3.1-1 shows a general spatial allocation of the mezzanine. The GBT Primary 
Processor, Control Processor, Mass memory and hard copy printing devices will be housed 
in the GBT Processing Center upstairs and adjacent to the Demonstration & Control Center. 
Both areas will have independently controllable environments designed to properly 
accommodate the data processing equipment, staff and visitors. Attention will be given to 
provide a view of high bay and staging area operations. Windowed partitions will be utilized 
to provide the designed view of the Processing Center and downstairs working areas while 
maintaining the controlled equipment. The Demonstration area will accommodate up to 20 
visitors in a design which permits a good view of the large screen monitors, projection 
screens and main control console. Individual control of the Demonstration Center 
temperature and lighting is imperative. 


21 ' 0 M - 
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Lab Control 
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Data Processing 
Area 




■ 21 ’ 6 " - 


_ r 

Demo Center 
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Software Development 
Area 


10 ' 6 ” 
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FIGURE 7. 2. 3. 1*1 MEZZANINE LAYOUT 
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Safety provisions for rapid egress from the mezzanine require two stairways. Provisions to 
protect the Primary Processing Center from fire and intrusion should be provided. A Halon 
system should be investigated. 

7. 2. 3. 2 Avionics Hardware Testbed (Hot Bench) and Staging Area 

Basic to the design of the GBT is its capability to evaluate candidate hardware in a closed- 
loop, simulated operational environment. The Target configuration will have the ability to 
interface with prototype hardware at both the box and system level. A Primary full capability 
test bed will be supplemented with staging area equipment capable of preliminary open loop 
and closed loop testing. The staging areas will enable a parallel and more efficient use of 
the GBT facilities. The large roll up type of doors will facilitate easy access to the two staging 
area test stations. The staging areas are adjacent to the upstairs processing facilities as well 
as electrical and hydraulic power sources. The space allocated for the Hardware Testbed 
and staging areas was sized to accommodate a prototype flight segment of 15 ft. diameter 
and 1 5 ft. height. 

7. 2. 3. 3 Guidance & Navigation 

Several requirements drove the location and configuration of this GBT resource lab. The 
future configuration of this lab called for dual 3-axis tables. The 10 x 25 x 10 foot isolation 
pad accommodates these units and the associated optical alignment equipment. The size of 
the pad and the ability to have a line-of-sight access to the North Star for alignment dictates 
the location within an addition on the north side of Bldg. 4476. 

7. 2. 3. 4 Placement of Other GBT Resources 

Due to the fluid nature of the already planned facility modifications and the August 1990 
Phase I IOC, specific placement of the other GBT resources is felt to be premature. 

Temporary facilities will have to be provided while Bldg. 4476 is being modified. 


8.0 GROUND BASED LAB PHASE 1 COST ESTIMATES 

Table 8.0.-1 gives the ROM costs associated with the Phase 1 GBT. Note that these costs do 
not reflect any fees or expenses associated with procurement. The hardware and software 
prices are "list prices". Software development costs reflect only a flat hourly cost. 
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TABLE 8.0-1 PHASE 1 GBT COSTS 


ORIGINAL PAGt fS 

9.0 SUMMARY AND CONCLUSIONS 0F Q UAL,TY 

The purpose in defining the philosophy, objectives and desired functional capabilities of the 
Ground Based Testbed was, of course, to provide a basis for implementation planning. 
Successful implementation will be judged upon the GBTs ability to provide timely and cost 
effective support to Shuttle C, STV and other emerging programs. Figure 9.0-1 reviews the 
basic functions provided by the GBT. The other factor which can not be neglected is funding 
for the implementation and operation of the GBT. All of these factors will be summarized in 
this section. 
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FIGURE 9.0-1 GBT 

FUNCTIONS 



9.1 GBT Functional Design 

To perform the Functions and provide the Test and Evaluation Features shown, the GBT 
design evolved into several functional elements. These elements in turn were sized to 
support specific program driven capabilities and requirements. The development of element 
capabilities was paced by projected funding levels and prioritized program support 
requirements. Where possible, provisions were made to use existing, related test and 
evaluation resources. These provisions, in most cases, not only provide an earlier 
operational capability, but also extend the original resources capabilities and effectively 
extend its operational life. 

The primary functional elements of the GBT are shown in Figure 9.1-1 and will be 
discussed in the following paragraphs. 

9.1.1 GBT Core 

The GBT has been described as spanning the test continuum from pure simulation to 
hardware performance evaluation. Common to each extreme is a flexible, high through-put 
core processor.The GBT core has a main processor which is functionally divided into the 
primary processor and the avionics system simulator. The primary processor function 
includes running the simulation of the test vehicle dynamics, the mission environment and all 
other interfacing elements to the vehicle avionics system.The avionics system simulation 
function includes running the simulation of the test vehicle avionics system. This includes the 
monitor and control of all interfaces to real hardware being tested or run on the Avionics 
Hardware Test Bench. 

Selection of this processor was one of the most important and far reaching design decisions 
of the study. The unit chosen combined an excellent cost to performance ratio with a 
software and hardware migration path capable of supporting the rapidly expanding 
simulation demands of the immediate future. Initially sized with a through put in excess of 
150 Million Instructions per Second, (MIPS), this expandable core processor has the 
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software tools and I/O ports to support the GBTs current and future Real-Time simulation 
requirements. 

The four other main elements of the GBT core are the Main Control Processor, Mass Storage 
Unit, Hard Copy Processor and Interconnecting network/buss structure. The Main Control 
Processor is primarily tasked with the allocation and control of GBT resources. It controls 
most of the various busses and networks running throughout the GBT and supervises use of 
the Mass Storage and Hard copy Processor. While functionally a part of the GBT Core, the 
Main Control Processor will probably reside in the Main Control and Demonstration center. 



FIGURE 9.1-1 GROUND BASED TESTBED TARGET CONFIGURATION 


9.1.2 Main Control & Demonstration Center 

Within this element rests the primary control and allocation of all the GBT resources. Central 
to its function is the Main Control Processor that is linked to all the available resources by an 
extensive inter / intra lab communications network. The Main Control Center and 
Demonstration Center are collocated because of their complementary functions. The 
Demonstration monitors may be used to supplement the status displays available to the 
core’s Main Control Processor. The graphics processors will also supplement the Main 
Control Processor in controlling parallel operations going on within the GBT. 

- — - The Demonstration Center primarily consists of four graphics processors driving four large 
screen monitors. The graphics processors are used to develop display and other support 


Page 85 „ _ 9/25/89, 11:40 AM 

ORSGiMAL 

OF POOR QUALITY 














Fma[ dSE2Ik £ 


Definition ofAvionics Concepts for a Heavy Lift Cargo Vehicle 


type graphics. Working with the large screen monitors, the processors can reproduce 
demonstration graphics depicting anything from real-time test parameters to reproduction of 
demonstration graphics. 

9.1.3 Avionics Hardware Test Bed 

The Avionics Hardware Test Bed is the third major segment of the GBT Target Configuration. 
It contains the interfacing units, busses and harnesses necessary to accommodate the GBT 
Benchmark hardware. The benchmark hardware is a collection of current avionics units 
which, when connected to the required interfacing harness, comprise a fully functional 
avionics system.lt provides a real world performance standard to which the candidate 
hardware can be compared. The Avionics Hardware Test Bed therefor facilitates 
development and evaluation of new avionics systems, and components by providing a high 
fidelity, native environment in which they can be tested. 

9.1.4 Guidance & Navigation Resource Lab 

The G&N Lab is one of the most important resources available to the GBT. Though capable 
of fully independent operation, in an acceptance test procedure role, its primary value is in 
closed-loop simulation of an integrated avionics system. The precision 3-axis table can 
supply all necessary stimuli, except acceleration, to evaluate the best inertial elements of the 
HLCV era. The Slave I/O interface box will provide the local real-time interfaces to 
accommodate such testing. 

9.1.5 Instrumentation Resource Lab 

The Instrumentation segment is a subset of the Avionics hardware test bed that permits local 
control and monitoring of the test bed hardware or units under test. It functionally duplicities 
an instrumentation ground station and is equipped to analyze vehicle bus traffic. 

9.1.6 Software Development Facility 

A major design driver is the architecture of the user friendly software that yielded the efficient 
and highly compatible interface for potential users. The cost effectiveness of GBT usage 
rests squarely on its accessibility and Its ability to accommodate several tasks in parallel. 

This translates to a modular set of software tools, tailorable to specific applications and 
executed with data that bounds the required performance regimes. The tailoring and 
selection of appropriate performance data is accomplished by a menu driven linkage 
process. The Software Development Facility will initially be located in the Main Control and 
Demonstration Facility while the basic GBT operational and benchmark software is being 
integrated. As the GBT phases into operation, the function of this element will shift to the 
primary user interface. It will become the site where users will assemble the modularized 
software tools and simulations into the desired testing regimes. The Software Development 
Facility will also host the building of the demonstration graphics. 

9.1.7 Navigation Aid & Image Processing Extension 

This GBT extension is scheduled for Phase 2 implementation. It is designed to provide 
developmental support for the autonomous rendezvous and docking aids in the near term 
and approach and landing systems for the far term Fly Back Booster. See HLCV Second 
Quarterly Review, Thursday 22 September 1988 for details. 
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9.1.8 Power System Extension 

This GBT extension will be capable of testing new technologies in Power Systems 
components and architectures. This Phase 2 extension will support not only the normal 
evaluation of candidate power system sources and architectures, but will be focused on EMA 
power supply development and testing. 

9.1.9 Fluids & Pneumatics Lab 

This GBT extension facility contains the hardware and special test equipment needed to test 
the new Fluids and Pneumatic architectures and components. The Fluids & Pneumatics Lab 
contains flow and pressure sensing equipment, pressure regulation equipment, electronic 
valves, a facility processor, a VME bus input/output interface chassis, and bottled fluids and 
gases.The extension facility shall have thick safety walls and a pressure pit for this high 
pressure LN 2 . The facility shall also be capable of running remote when operating with the 
high pressure. 

9.1.10 Actuator Lab 

This resource lab will provide a dynamic performance evaluation facility primarily aimed at 
larger, fast response actuators used in Trust Vector Control systems. With the emergence of 
large numbers of clustered engines as a solution to the heavy lift booster requirements, 

EMAs are gaining popularity. The advantages of being able to link the Power Systems and 
Actuator Labs together via the GBT is seen as an attractive Phase 2 capability. 

9.1.11 Propulsion Systems Labs 

MSFC has long been the site of propulsion system development and test. The GBT would 
provide a way to combine the existing, high fidelity,. propulsion system hardware emulations 
and simulations with the avionics system simulations to provide integrated, end to end 
testing. Particularly useful will be the capability to evaluate control system performance using 
the clustered engine configurations of the future. 


9.2 GBT Implementation 

From the beginning, it was recognized that the Ground Based Test beds capabilities would 
be tied to meeting current program system testing requirements. The GBTs role was to 
encompass vehicle simulation and testing needs from inception to the Preliminary Design 
Review (PDR). Looking at the projected vehicle developmental schedules, it was all too clear 
that the first operational GBT capabilities would have to be focused on the critical 
developmental problems. If vehicles like the Shuttle C or STV were to be supported prior to 
their PDR's the GBT must be at least operational by August 1990. 

Software model development is another key factor in the implementation plan. Fidelity of the 
vehicle dynamic and system models is critical to establishing the GBT as a valuable program 
development resource. This usually requires actual hardware being used to develop and 
verify the fidelity of the respective software models. Availability of similar hardware often 
proves to be another pacing element. The basic GBT hardware and software design is 
modular and thus can be changed easily to accommodate different requirements. The early 
phases of implementation require the building of a specific number of these basic modules to 
satisfy a limited number of needs. To satisfy a greater set of requirements relatively few new 
modules are required. 
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LAB PRELIMINARY IMPLEMENTATION SCHEDULE 
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FIGURE 9.2-1 IMPLEMENTATION SCHEDULE 


Figure 9.2-1 shows an early implementation schedule and its assumptions. One of the most 
difficult problems of the implementation schedule, shown earlier in figure 1.2-2, is the amount 
of work to be done in the first phase. Between February 1989 and August 1990, over 60% of 
the total task must be accomplished. This is not consist with the relatively low front end 
funding guidelines that were provided for this study. Figure 9.2-2 shows this problem 
graphicall 


IMPLEMENTATION ISSUES 
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FIGURE 9.2-2 PROJECTED FUNDING LEVELS VS TASK 
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9.3 GBT Funding 

The bottom line for GBT success is being able to supply the most cost effective and useful test 
facility at the time when new programs need it the most. This implies that the projects are 
willing to pay their way and plan for such usage initially. This idealistic form of funding must 
be recognized as supplemental to basic level of funding needed to initially implement and 
later maintain GBT operations. Internal Research & Development projects are also a source 
of funding. This type of function typically accelerates the application of useful, new 
technologies and test concepts upon which later major programs are built. 

Table 9.3-1 shows a summary of the element costs associated with the Phase 1 Ground 
Based Test Bed. Note that these are ROM costs with no wraps. More up to date, loaded 
costs are available in the Final Report Addendum. 



